[DGD] Persistent library design, initialization and data integrity

Carter Cheng carter_cheng at yahoo.com
Tue Oct 16 14:30:50 CEST 2007


One of the most salient features of DGD is persistence. As noted on a previous thread on the mailing list in theory this means that most initialization code can be for the most part done away with since many objects need to be only initialized once. In my experience from working primarily with MudOS 90% or more of the code is designed to support initialization or initialization code of some sort. 

I am curious what happens when you start avoiding the initialization script approach to initializing things on persistent muds. Do you have to be more concerned about data integrity since the data might be the only place where that information is kept (there is no redundancy of an init script or a save file). So instead of spending security effort protecting files you (following this line of reasoning) have to protect data just as much. 

This seems like to me it might have two implications- either security has finer granularity (is this possible under either Klib or Phantasmal?) and you can fine tune the system to make sure certain calls are restricted to certain classes of users depending on the object. Or you would have to add extra code to each set type call in turn to make sure that it isnt called by someone lacking proper permissions.

Is this true and are there other implications also when designing persistent mudlibs?







More information about the DGD mailing list