[Prev][Next][Index][Thread]

# Re: turning player_db and match_player into builtins..

- Date: Mon, 23 Sep 1996 19:07:09 PDT
- From:
- Cc: "'moocows'" <moo-cows@parc.xerox.com>
- Content-Type: TEXT/PLAIN; charset=US-ASCII
- In-Reply-To: <32469420@msgate.litc.lockheed.com>

    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:

- Re: turning player_db and match_player into builtins..

- From: "Adams, Charles" <cadams@msgate.litc.lockheed.com>

- Prev: Re: turning player_db and match_player into builtins..
- Next: Re: turning player_db and match_player into builtins..
- Index: MOO-cows
- Thread: MOO-cows

Home | Subject Index | Thread Index