[MUD-Dev] Persistent Worlds

[Jon Lambert]

Ryan Rhodes wrote:
> > Jon Lambert wrote:
> 
> I'm not sure I understand what you mean by "hard" and "soft" threaded
> servers???

I call an application soft-threaded if it does multi-tasking without 
using operating system threads.  

For example in CoolMud... after each opcode of task is executed by the 
VM, a tick counter is incremented, when that counter has reached 
a certain number of ticks that state of the task is saved and next 
task in the queue is executed.  Eventually one gets back to this task 
and returns to executing it.  After so many slices of time the task 
will timeout and fail.  This is also called time-slicing.  Muq and
Cold behave similarly.  

> Question: It would seem as though if you can abstractly map a compile
> time class to an RDBMs you can use the same process to map a runtime
> class.  When you say "NO" above, are you speaking of the heavy
> overhead of creating tables and handling the joins within the game or
> are you saying no its not logically possible to map between the two?

Well yeah you could write code that backs up the class/table in question,
redefines it, and then copies or reloads it from the backup filling in
the new fields with defaults or leaving out the deleted fields.  
You could also use SQLs ALTER on the class/table in question adding
new fields or deleting old fields.  That's how schema are changed on
the fly.  Most but not all RDBMSs support that.  I mentioned the method
where one uses the RDBMS as a monolithic table of rows of Object IDs 
and BLOBs (or IMAGEs depending on your RDBMS terminology).  The BLOBs 
or IMAGEs are just binary memory dumps of the objects.  And then there 
is mapping of the OO model itself into the RDBMS.  I made a post or 
two on that.  It involves defining your own OO catalogs (much like 
SYSTABLES and SYSCOLUMNS) and using those catalogs to reconstruct an 
object from multiple tables.  It's either heavy on the joins and/or 
requires building multiple SQL statements to retrieve an entire object. 
The nice side effect here is the presence of an externally accessible
catalog of the muds object model.  

Those are 4 ways I can think of. 

> The biggest issue I have in general with storing a runtime morphic mud
> is independent of how its stored.  How in the hell do you handle
> objects being recoded for modifications, reguardless of weather you
> store it as a blob, in an off the shelf DB, or on a homegrown DB.
> This sounds unclear, let me give an example:
> 
> You code a wizards cloak with a hood that needs to store a boolean for
> hoodup / hooddown.  It proliferates through the game and players have
> them saved on their character.  Now you recode it and add a zipper
> pocket, also needing the boolean for the same reason.  Do you update
> all the records immediately, adding the new field?  Now lets say you
> recode it again and tak e the zipper pocket off.  Do you just lose
> that field altogether in the DB for all instances?  This is a stupid
> example but it becomes alot more relevent with complex items where, in
> the recoding you may have changed the use of the data.  Old values may
> now be out of range.  Swords become awsomely powerful... etc.  The
> alternative would seem to re-initialize instances in the DB when their
> cooresponding class has been updated / recoded, but now you've lost
> all your information.  How is this handled normally?

Right.  This is a different topic entirely.  I think in OO systems you have
two sets of problems.  The first is dynamic class/object versioning, the 
second is dynamic inheritence/reparenting.  The nature of the solution 
of course varies among the different object models.  

If I were using Java, I suppose for the first case, classes/objects that 
have their attributes extended or deleted, I would write out to the DB 
all existing objects of the changed class.  Then I would reload the new 
class and maybe use some of the reflection functions of Java to repopulate 
the instances from the old class data.  

For the second case, that of an inheritance tree changing, I have no 
clue whether its even allowable in Java, or whether it creates class
loading errors.  But if it is allowed, it's probably going to be a 
messy operation anyway.  

To illustrate... 

  OBJECT
   \
   THING
     \
     WEAPON ---- 
       \        \  
       SWORD    POLEARM
       |     \
      MYSWORD YOURSWORD (instances) 

Now suppose I create classes called OneHand and TwoHand 
with the intention of.....

  OBJECT
   \
   THING
     \
     WEAPON ------ 
       \          \  
       ONEHAND    TWOHAND
       |            \
       SWORD         POLEARM
       |     \
      MYSWORD YOURSWORD (instances)


Now I do handle these sorts of operations in Aphrodite, but the object 
model is different than Java's.  Changing the inheritance tree is an 
expensive operation for me while changing attributes of classes is a 
fairly cheap operation.   

--
--* Jon A. Lambert - TychoMUD        Email:jlsysinc at ix.netcom.com *--
--* Mud Server Developer's Page <http://tychomud.home.netcom.com> *--
--* If I had known it was harmless, I would have killed it myself.*--
 
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev