[Home] [Groups] - Message: [Prev in Group] [Next in Group]

nu.kanga.list.mud-dev

5033: Re: [MUD-Dev] Persistant storage.... My current idea.

[Full Header] [Plain Text]
From: "Jon A. Lambert" <jlsysinc@ix.netcom.com>
Newsgroups: nu.kanga.list.mud-dev
Date: Sun, 29 Mar 1998 01:27:38 -5
References: [1]
Organization: Kanga.Nu
On 28 Mar 98 at 21:53, Ben Greear wrote:
> *********************
> 
> I'm currently planning on using one file, with certain blocks
> allocated within it for objects.  It will basically be a linked
> list represented as a file.
> 
> I'll have headers that point the the seek position of the next and
> previous element in the file.  It will also keep track of the used and
> total space allocated for that element.
> 
> If I need to update, and it's too big, it will be moved to the end
> of the file, and the previous element will get it's space.  (I'll deal
> with boundary cases, sufice it to say.)
> 
> Now, this reeks of inneficiency when trying to look up an object based on
> some key (object number in my case, probably 8 bytes ).
> 
> However, I'm going to create a hash table at boot time to link an object
> id with the seek position of that object in the file.  I believe this
> should give me as quick access as I can expect.
> 
> *************************

Why not put your headers (pointers to the seek pos)
into a separate file, an index file.

Then you'd be very similar to an xDBM or ISAM. :)

> Some other things:  I'll have objects unique across the universe, even
> different servers.  (Each server will be assigned an ID, and each object
> within that server will have a unique ID.  So, given both ID's, I can
> guarantee uniqueness.)
>

Very much like COOL.. 

struct ObjID {
	short serverid;
	int   objectid;
}
 
 
--
--/*\ Jon A. Lambert - TychoMUD     Internet:jlsysinc@ix.netcom.com /*\--
--/*\ Mud Server Developer's Page <http://www.netcom.com/~jlsysinc> /*\--
--/*\   "Everything that deceives may be said to enchant" - Plato   /*\--