MOO-cows Mailing List Archive
Re: Suggestion, re: Minimal.db
GRAEME SMITH email: firstname.lastname@example.org
2536 138A ave Edmonton
On Wed, 29 Nov 1995, Lionel Clark wrote:
> I use the Book object a lot. I picked it up at Ranalou's
> place and the book object I had there for the longest time was
> the BEST - small, simple and very usable. Noteditor works
> perfectly with it, and all my jottings are collected. This
> objectis not in the Minimal - am I the only person who really
> likes this object?
Well, my own personal plans are on record... ref my implimentation
plan for Mod0 of NewCore I am currently setting up the mechanisms
so that you can inherit across moos, sets of useful objects called
MOOdules and integrate them into your moo without worry about numbering
dependencies, and all that sort of stuff. To start with, I am Modularizing
the core, and the first step, is.... stripping it of everything but
the BBS level Access stuff. The idea I have, is simple, put the neat
interesting stuff into modules, and port the whole module accross so
people that want a library, can have more than one book....Qua?
A Minimal... isn't really the same as the CORE though, I think you are
missing the point.... if someone has his way, it will consist of only
a few bytes. Now that is MINIMAL, and also probably pretty useless, without
a LOT of development. In fact, there is no reason why you even need a minimal
database, if it is that small, just write a function to generate it the first
time the MOO is run, and doesn't have a database defined.
> The Autoport is a great mechanism. I think if the
> stablest forms can be compared and a best one chosen, that winner
> should be placed in the new Minimal. Whatever qualifies for
> 'best' is anyone's guess, however I like having it on one object
> as suggested.
As I suggested before I think you are mistaking the difference between
a Minimal, and a CORE.
> A variation on this theme, perhaps - an AutoPorter that
> would interface with an FTP site to update or requests updates of
> various objects. That way, when perhaps a new version of say
> notedit is released, those interested can update their system
> easily and with great confidence.
Not a bad idea.... I like it!
> This may necessitate a standard for Moos - like #0, some
> place where autoport can find pointers to 'known' objects -
> perhaps Everyman has changed, or something like that. That way
> Autoport can correct code that is made Autoportable via keywords
> in comments, etc, and make sure that the code will use the same
> objects on the destination system.
Well if you look at my implimentation notes, #7 defines a new generic,
a sort of Macro Object, that contains other objects (for the purpose of
porting them). #8 is the first instantiation of that object. And #6 contains
a list of the Modules that are part of the MOO.
I think that this is a start in the right direction as it reduces the number
of objects that have to be separately listed, and thus the size and
processing load of searching them.
Subject Index |