Of disk swapping, database structure & project management..

[coder at ibm.net]

On 01/05/97 at 09:03 PM, Greg Munt <greg at uni-corn.demon.co.uk> said:

>Has anyone experimented with swapping unused parts of the mud database to
> disk, reading it back in when needed? What sort of format is it stored
>in  (eg binary, ASCII, etc)?

Not exactly.  I do the exact reverse.  I keep the entire DB on disk and
work from that.  As such everything lives on disk and nothing lives in
RAM.  My DB module reads in objects from the disk as they are requested,
and writes them back out as they are changed.  As such I keep damned
little in memory at any time.

All this being true, I also run a large cache and try as much as possible
to minimise the reads/writes with clever cache management, staging,
delayed writes, etc.

>Also, what were your considerations when designing the structure of the 
>db (both memory and disk images) - ie i have a hex tree (like binary 
>tree, but with 16 child nodes instead of 2), but im not sure how 
>efficient it is.. a number of calculations have to be made to progress 
>down each 'level' of the tree, I was wondering what other ppl had done?

My DB is a strict linear affair.  As discussed earlier my Objects have a
unique ObjectID, a 64bit value composed of a 32bit timestamp of creation,
and a 32bit record #.  The record # half maps directly to the object's
position in the DB.  I don't use any clever searching techniques as pretty
well everything knows the ObjectID of what it wants in advance.

>Now my project report has been handed in (phew) I can now accept 
>contributions from others. At the present time, there are about three or 
>four interested parties. Has anyone had any particularly good/bad 
>experiences related to project management in the area of mud development?

I'm a contract programmer, so I have *lots* of war stories of bad project
management, etc etc etc yada yada.  Up front suggestions:

  Establish a set of agreed upon base purposes for the project up 
    front.
  Establish a set of agreed upon base principles up front.
  Have one guy be the boss.
  Have the boss'es final word be the final law without argument.
  *NEVER* attempt to work via democracy or concensus.
  Assign responsibilities in clearly defined areas/boxes.
  Attempt to minimise the extent to which those boxes overlap.
  Attempt to minimise the extent to which those boxes inter-depend.
  Base all decisions on stated principles.
  Re-state the base principles used in making decisions, especially 
    if contested.
  If a decision doesn't rest on solid base principles it ain't worth 
    squat.

>The more I travel up the learning curve, the steeper it seems to get.. 
>ah, but I'll get there in the end (wont i??)

Nahh, its an asymptotic curve that occassionally reflexes back to 0,

--
J C Lawrence                               Internet: claw at null.net
----------(*)                              Internet: coder at ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...