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

Re: Minimal.DB



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.
References:
Home | Subject Index | Thread Index