MOO-cows Mailing List Archive


Re: [DISCUSSION] a core

>>Interesting point... although the point of a core is to be 'generic', and exist
>>as a jumping off point for bigger and better things.  A core is just the
>>basics -- all the things you think you might need to get a job done.  What
>>that job is is not up to the core.  I don't expect the core to do everything
>>I want... what would be the fun in that? 
>Personally, I would like to have a core that follows the spirit of the
>excellent system Dave Van Buren has on AstroVR, only even more so:
I think all cores should be like every other core, but even more so.

>Have a generic core that does the things that are more-or-less basic to all
>MOOs.  Then around this central System Core, have subsidiary cores to handle
>specialized tasks, e.g., Mathematica Core to handle interactions with an
>external Mathematica server, Help Core, FTP Core, Mail Core, NNTP Core,
>Gopher Core, HTML Core, Client Core, Web Core, etc., etc.  Each Core object
>would in turn point to associated objects (Database, Utilities, Documentation,
>etc.) and this object cluster would be in charge of handling all the
>associated functionality.
You have, of course, forgotten about the Zen core.  The beauty of the Zen core
is that it's already there, especially if you try to remove it.  You have also
forgotten the City core which would be useful for (perhaps) T'Hung'AmOO, due
out March, 1996.

>These subsidiary cores could be made highly modular, and a transporter system
>could be created for importing/exporting the modules from one MOO to another.
I don't think the object-oriented server lends itself to modular coding.  We
have to overcome this inherent limitation before we begin on this project.
Of course, the Zen core is fully modular and transportable.

>(The ability to analyze the inheritance structure that I've been talking
>about would be extremely useful for handling the obvious difficulties that
>arise in such a system, since you would need a way to know what builtin
>functions are available, what dependencies exist, and so forth, to have
>any hopes of making an efficient automatic transporter sytem.)
I don't care about efficiency.  I need effectivity.

>This would then be a hybridization between an object-oriented approach and
>a function-oriented approach, and would allow one to plug-and-play,
>rather than scrounge-around-and-hope-I-can-make-it-work-in-my-MOO like
>we currently do.
So, we are running Windblows 3.1x, and not Winslows '95.  I will be in charge
of licensing the technology from Intel and Microsoft if no one else will do

>It would also, IMHO, make MOO more scalable and portable.
>Certainly, large MOOs are out there (Lambda alone is gigantic), but
>exporting/importing code from one MOO to the next is anything but standardized.
The great thing about gigantic, non-standard MOOs is that people can stand
around and talk.  Just like ZenMOO (telnet://
They are seated on the ground, under a Cordoban olive tree, the kind that,
according to the popular quatrain, makes the oil yellow, as if olive oil
weren't yellow, or only occasionally slightly greenish, and the first words
from Jose Anaico, he could not suppress them, were, This place is enough to
put the fear of God into you, and Pedro Orce replied, It's much worse in
Venta Micena, where I was born, an ambiguous formality that means what it
appears to be saying as well as the exact opposite, depending more on the
reader than on the reading, although the latter is entirely dependant on
the former, which explains why we find it so difficult to know who is
reading what has been read, or the effect of what has been read on the
person who reads it, let us hope that, in this case, Pedro Orce will not
think that the curse on the place is a result of his having been born there.
                             -Jose Saramago, _The_Stone_Raft_

Home | Subject Index | Thread Index