# Minimal.DB

Graeme Smith (grysmith@freenet.edmonton.ab.ca)
Tue, 14 Nov 1995 15:21:20 PST

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    GRAEME SMITH                         email: grysmith@freenet.edmonton.ab.ca
    2536 138A ave Edmonton

    On Tue, 14 Nov 1995, Seth I. Rich wrote:

    > So I was once again hacking minimal.db, and I notice that I'm always
    > starting with the same steps.  Why doesn't minimal.db consist of a single
    > object, #0, which is a player and a programmer and a wizard, with a
    > :do_login_command verb which returns #0?  I don't see any reason for
    > minimal.db to contain a room or root parents at all.
    >
    > Seth / Blackbriar
    > ----------------------------------------------------------------------
    > Seth I. Rich
    > Woo, woo!  OpalMOO's back!       There is nothing more precious than
    > Rabbits on walls, no problem.    a tear of true repentance.
    >

    So there I was, Hacking away at Minimal.db when I got this message....

    Uh, Seth, you remember me,... dbase update query a few weeks ago...

    I am presently working on a Dbase I call NewCore which will be implimented
    in MOO-1.7.8p4, and I think I might know of an answer, to your question.

    First of all, the Minimal.db has only 4 objects, which is not an excessive
    waste. But to further reduce them while possible seems somewhat unnecessary.

    The whole idea of building that particular pattern of objects, is that it
    is the minimum number of objects needed to impliment a structure similar
    to that used to login to LambdaCore. It clearly shows the nature of the
    difference between a character and a room, between a system object, and
    a root. I found it quite useful.

    Your omnibus object on the other hand, would not give you the same level
    of selectivity and would in fact, be in limbo. Further, any objects based
    on it, would themselves be characters, rooms, system objects, and so on
    all at once. I think straightening that kink out would cost a few objects
    in the long run.

    Personally, I am planning on a Module I call Module0 that is an extension
    of the Minimal DB, limited to about 6 objects. It will contain, a logon
    character, the Archwizard, a Logon Room, a System Object, and a System
    Options object. All of these will be referenced in a final Module Object.

    The purpose here is to deal with Security concerns in a manner that keeps
    the Database intact, yet segregates the Server Oriented components from
    the rest of the Database. If I attempted to use the same object as my
    archwizard and my logon character, anyone logging on, would get the same
    unlimited access the archwizard would get. If I used the same room for
    both, then anyone signing on would have the server commands, available
    and might, for instance decide to shutdown the server without authorization.

    As long as .program is available, I want the server commands segregated
    from the logon character... wouldn't you?
    >
    >
    by the way, I have heard rumors of OpalCore....

    do you know where I could get a peek at it?

    				Grey

    		A Newbie Archwizard that is Modularizing the Core out
    		of sheer frustration with its lack of Maintainability.