MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

Re: turning player_db and match_player into builtins..



GRAEME SMITH                         email: grysmith@freenet.edmonton.ab.ca 
YMCA Edmonton             
(Back on line!>

On Mon, 23 Sep 1996, Adams, Charles wrote:

> How does this compare to the trie structure the database currently uses for 
> the player db?  

Hmmm... Trie might be the same as Treive ... Are you Sure, that it does a
Trie? Of course I could be being confused by the serial nature of the
Database, into thinking that it is using a serial list. But if it is already
using a treive technique then the length of the database, has less impact
than the depth of the search tree. 

My feeling is the $0:Player_db or some similar object is the actual trie
object, and that the server is simply implimenting serial lists. Eric has
mentioned wanting to develop tables, and light weight objects at the server
level, but some of us are not convinced that it is necessary.

>  As a matter of fact, tries are perfect for string prefix 
> match comparison, which might be why they chose that structure when building 
> lambdacore's $player_db.  You never mention the word "trie" once, and go on 
> quite a bit about completely unrelated subjects such as threads.


Such are the problems of speaking across borders. We might call the same
technique by 3 or 4 different names.

> Lemme get this straight:  It's wired into the server for greater 
> flexibility?

Hmmm..... wired into the server???

not exactly, as I attempted to suggest, because of the nature of the software
wiring it into the server will not assure good service of the server, if by
that you mean hacking the treive (trie) technology into the server.

On the other hand, building it on the system level, just above the server,
which is what you do when you rewrite a core, is better in my books, because
at the database level, you already have multi-programming implimented, and
one person spending lots of time doing database acesses, won't slow down the
server for everyone else.

The ability to build a GENERIC TREIVE Referenced Object, is part of what I
call Database-inDB technology. Essentially I am building a multi-level 
database structure, a Database within a database or Database-inDB.
 
> 
> I'd like to see tables in-server as well, but I fail to see where all this 
> talk about B-trees or B+ trees is headed.  I'd also like to see tables that 
> could be tied to an external dbm (ala perl5's 'tie' function) but I'm not 
> holding my breath.
> 

A B+ tree, is both a trie, and a linked serial list. B- trees, are like tries
as near as I can figure out from the descriptions. (Having never taken that
part of the modern computer programming courseware). They are different terms
because they are used often in different manners. Because the Server does not
have native disk access, the usual B+tree application as a method of file
handling is not possible, but the same effect might be possible for object
management.

You want to be able to design a better user database.

GREAT!

I am playing with the idea of making it easier to do, by putting more tools
into the basic moo database. Those of you that have recieved my MOD0 version
of newcore, may be aware that the core has implimented basic multi-user caps
without breaking modularization as badly as Lambda Based Cores did. I have
included tools such as in-db crypt functions, and local flagging functions
to limit the role of the remote wizards if that is desireable. But Mod0 is
still a relatively bare bones database, and does not impliment MOO-Lang, or
even proper mail interfaces. Mod1, is oriented around the idea that 
having a more flexible DATABASE interface in-core, is desireable. Server
builtin-functions do not include true trie technology, (which is what I
was saying in my earlier note) So it has to be implimented in-db.


Reading this I doubt if I have made it any clearer, but the meat is there
if you want to figure out what I am talking about.

				GREY
References:
Home | Subject Index | Thread Index