Subject: Distributing New Cores, Object Numbers

From: Steven Owens <[email-masked]>
Date: Fri, 5 Nov 1993 09:39:54 -0800

I've been tinkering about with some ideas for mechanisms to transfer
objects between MOOs and such (any suggestions and information on that
would be greatly appreciated, particularly pointers to working
implementations I can learn from).

In looking for information about this, I've come across a few
instances where people are asking for an easier way to update to a new
core release.  What exactly makes it so hard?  I can guess, but I'm
wondering if there's more than meets the eye.

If it's simply a matter of dealing with object numbers, I can see how
it would be awkward to add new objects when they default to numbers
already in use, but that's relatively simple to resolve (I think).  How
about simply reserving the first, oh, 3000 object numbers for core use?

The first thousand could be reserved for core objects.  Any new
objects that are part of the essential core would be in this range.

The second thousand could be for optional objects; for example, if the
object-oriented mail system was completed and added to the optional
core, its generics would go here.

The third thousand could be for local core objects, so modifications that
the wizards of a "satellite" MOO decide are good 'nuff to corify go here,
so as to avoid stomping on namespace reserved for essential core or optional
core distributions.

Obviously, the 1-2000 range would be kept pristine - nothing altered, all
modifications done on descendants.  This would allow new versions to be
plugged right in, as long as they were "backward compatible."

This seems like such a simple solution, I have to feel I'm missing
something.  So what is it?

Steven J. Owens
[email-masked]
Puff @ LambdaMOO, OpalMOO, JaysHouseMOO, MediaMOO, MetaverseMOO, GNA, etc.

---

From: "Jacqueline D. Hamilton" <[email-masked]>
Date: Fri, 5 Nov 1993 17:44:04 -0800

> about simply reserving the first, oh, 3000 object numbers for core use?

Well if you create 3000 objects just to reserve the numbers, you've 
immediately got a 6 meg (?) or so database to start off with, thats 12
meg or more in core, without even building anything.

However its still a usable idea (not mine tho, Ted/Falryx and Josh/
Shirgall started it) :)  and we're using it on MOOns and HT (altho
HT only reserves up to 100 for core objects).

At any rate we create #76(?)-#100 as "core saving objects" and stow them
til later.  100 may not be enough of a margin though, perhaps 1-300?
This allows for a healthy amount of core growth, for sure.

Upgrading cores tho... doesn't seem as easy as just @dumping a new core
and replacing an old one... I'd expect you'd want to proceed carefully
and on a spare used copy of your db in case you trash the place.  We've
been careful not to touch the core much at all - we put it all on $ref
objects - $ref.player=> generic player II, $ref.room => generic room II,
etc, so its possible we *might* be able to make a clean upgrade.  Still,
I'd be a little wary of losing things, and we *do* still have core changes 
on our db now, (some documented, some probably not).  And any way you do
it its going to be time consuming.  

And anyway it doesnt help all the various MOOs that didnt start this way...
:)

Cool idea tho.  Perhaps one of these days I'll try fixing HT's core.
It'd be easier if we knew what had been changed and only fix those things.
I am so reluctant to use @dump.  Already seen what it can do to 
reparented players... :)

-j.