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

# Re: Minimal.DB

- Date: Thu, 16 Nov 1995 10:34:28 PST
- From:
- Cc: moo-cows@parc.xerox.com
- Content-Type: TEXT/PLAIN; charset=US-ASCII
- In-Reply-To: <Pine.BSI.3.91.951116112026.19614A-100000@server.icon-stl.net>

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

    On Thu, 16 Nov 1995, Timothy C. Brown wrote:

    > This is (IMHO as usual) a Good Idea (tm).  The reason why I say this is I
    > have something to add to it first.  The cool thing about this idea is we
    > could (as necessary) insert/delete program libraries as needed.  What I
    > mean is, we can take a FUP-type approach (like the wizards over at
    > RiverMOO have done) to move most of the database out to disk and then read
    > it back in (the modules, that is)....
    >
    > So, for example.  Let's say the multicommunication feature (for example)
    > is not being used at this point.  Somebody throws out a request (running
    > a verb on it) and the server imports the communications module (with the
    > MC feature) and runs it, then dropping it back out if it isn't used in 15
    > minutes or whatever.
    >
    > This may make processing time on verbs a little slower, but it could also
    > speed it up seeing as how the MOO's in-memory size is decreased.
    >
    > Ideas?  Comments?  Am I totally unintelligible here?
    >
    > Tim/Phylon
    >
    > Timothy Brown <tbrown@icon-stl.net>
    > http://www.icon-stl.net/~tbrown/
    >
    > On Thu, 16 Nov 1995, Graeme Smith wrote:
    >
    > >
    > >
    > > GRAEME SMITH                         email: grysmith@freenet.edmonton.ab.ca
    > > 2536 138A ave Edmonton
    > >
    > > In my opinion, there should be a functional range of cores, with tradeable
    > > components or Modules, oriented towards specific functions, and specific
    > > applications.
    > >
    > > In NewCore, I am considering the following breakdown:
    > >
    > > Mod0.db   A slightly more sophisticated version of Minimal.db with
    > >           Lambda style multiple user capabilities, and a SuperWizard
    > >           Called Archwizard oriented towards maintenance of the Db.
    > >
    > > Mod1.db   A Module to add to Mod0.db adding a necessary Guest Level
    > > 	  Character, Detailed rooms, and Feature Objects, or Verb Libraries
    > > 	  etc.
    > >
    > > Mod2.db   A Module to add basic Programming capabilities
    > > 	  an editor, Toolkits, and utilities, the base level programmer
    > > 	  and a help system, Tutorial system etc.
    > >
    > > Mod3.db   A Module to add basic building capabilities
    > > 	  Generic Rooms, special Rooms for building in, special
    > > 	  building tools...etc.
    > >
    > > Mod4.db   A Module to introduce Player Diversity
    > >
    > > Mod5.db   A module to introduce controlled melding of objects
    > > 	  and thus to allow multiple inheritance
    > >
    > > Mod6.db   A module to introduce Library Functions for swapping in
    > > 	  and out Modules as needed.
    > >
    > > Mod7.db   A module to introduce advanced vr techniques
    > > 	  such as morphing etc.
    > >
    > > Mod8.db   A module to introduce network interconnectivity
    > >
    > > etc.
    > >
    > > Once the basic System was modularized in this manner, and so that the
    > > dependencies between the modules are obvious, and declared, it could
    > > then be combined with a file system and Application Libraries. Essentially
    > > turning the Core itself into a Dynamic Link Library of Unique Objects, and
    > > Useful Verbs. The Modules could then be mixed and matched to create specific
    > > environments.
    > >
    > > IMHO that is a far superior Database, than the mostly adhoc ones that we
    > > see today.... of course the selection of functions and the order is open
    > > for debate, as I am just starting work on Mod0, and expect to be tied down
    > > with it, for an extended period as I attempt to perfect it. :)
    > >
    > > A newbie Archwizard that is Modularizing the Core out of Sheer Frustration
    > > at it's lack of maintainability.
    > >
    Yes I think you caught the gist of the project.... of course it isn't
    zenmoo, or Seths single object moo, but it capture the essence of simplicity
    by design, complexity by extension. Don't do the same thing twice, etc...
    all the good design doctrines....

    The question of whether Fup, is the best approach is of course meat for
    a different discussion, and I have no oppinion at this point. Essentially
    what I see the group, that I am starting doing, is building the Modular
    coding environment to make such modular swap-outs possible. I just suggested
    that the ability to access a library of modules would be valuable :)

    			Grey

    in order not to spam this list, please aim at least a few of the comments
    and suggestions through the Email, and not over the MailServer so as to

Follow-Ups:

- Re: Minimal.DB

- From: William Kaster <wsk@hpssl100.mayfield.hp.com>

References:

- Re: Minimal.DB

- From: "Timothy C. Brown" <tbrown@icon-stl.net>

- Prev: Re: Minimal.DB
- Next: Re: Minimal.DB
- Index: MOO-cows
- Thread: MOO-cows

Home | Subject Index | Thread Index