Subject: Multiple Databases

From: "Bob Monsen" <[email-masked]>
Date: Fri, 24 Sep 1993 14:46:10 -0700

Reply from the
desk of
                                                             Bob Monsen
 Subject:   Multiple Databases
A useful change to the server would be the addition of support for multiple
database files. Calling these new database files 'packages' clarifies things
slightly. One of these packages would be the "local" database, which contains
all local changes, and which is the only thing saved when checkpointing.
Another would be the "core" package, which contains what the current LambdaMoo
core contains (perhaps minus some functions that could be packaged separately).

I've already suggested something similar to this to Mr Curtis, but a more
general scheme would be useful for distributing the "packages" that were
suggested by [email-masked]. Each object would need to have a
property containing its package, and possibly a list of prerequisite packages
that would be required to run.

Initially, there would be two packages, "core" and "local". The "core" package
would contain everything thats currently in the core database. The "local"
package would be used for creation of new objects. New packages could be
created as needed by changing the home package of an object (a wizardly
operation). The dump-database verb would be changed to dump a set of packages,
or even a named package, and checkpointing would only dump the "local" package.

One could easily distribute things like "Mr Spell" using this scheme, or have a
package for a dungeon & dragon simulator.

Note that there is already a scheme for separating the core objects from the
local objects for creating core databases. This is a conceptual extension to
that facility.

Having browsed the LambdaMoo server source, it looks like this sort of change
would be very easy to implement.

Comments?

Bob Monsen
Apple Computer

--------------------------------------
Date: 9/24/93 10:57
To: Bob Monsen
From: [email-masked]
I don't know how "implementable" it would be, but it would be really nice if
some core objects could be made available in "options packages," like little
core dumps of very select objects which could be loaded into existing DB's
with a wizardly "patch()" function. That way, anyone who actually had a need
for Mr. Spell (for example) could go get it off parcftp, and everyone else
need not worry about "what is this for and how do I use it and why does it
take up 40% of the distribution core?" Also, those with established DB's would
be able to patch in neato new stuff like $gopher et al. Presumably, it would
work to have a function that just commandeered the next few available objnum's
and added the necessary props to #0.

====Rob (CF/Albion/Gelfin).

------------------ RFC822 Header Follows ------------------
From: [email-masked]
id <11848(4)>; Fri, 24 Sep 1993 10:37:26 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id
<58382>; Fri, 24 Sep 1993 10:34:18 -0700
Received: from sun4.math.uah.edu ([146.229.6.1]) by alpha.xerox.com with SMTP
id <11874(2)>; Fri, 24 Sep 1993 10:33:59 PDT
Received: by sun4.math.uah.edu (4.1/1.34)
	id AA06961; Fri, 24 Sep 93 12:22:36 CDT
Date: 	Fri, 24 Sep 1993 10:22:36 PDT
Illegal-Object: Syntax error in From: address found on alpha.xerox.com:
	From:	[email-masked] (Rob Thomas 890-7033	 Mathematical Sciences
Dept., Univ. of Alabama-Huntsville))
															^-illegal special character in phrase
Message-Id: <[email-masked]>
To: [email-masked]
Subject: Just an idea...

---

From: Judy Anderson <[email-masked]>
Date: Fri, 24 Sep 1993 14:52:52 -0700

Ah, the "scheme for separating the core objects from the local objects
for creating core databases" is quite destructive: it recycle()s all
non-core objects, and then uses renumber() on all the remaining
objects to compact things, finally ending with a reset_max_object().
This is done to a separate copy of the LambdaMOO database, producing a
much smaller core database.  Quite a bit of massaging of the objects
is done also, to prevent recycled object references, messages on
mailing lists, etc. from escaping into the resulting core.  Usually we
screw up and someone has to tell us what they found in the core so we
can fix the code for the future.

I don't know enough about how the server communicates with the
database to know whether your scheme would be workable: what would you
do about object numbers?  How would you save your objects out if you
wanted to make a local change to the core database?  How would you
specify which database a newly created object went in?  Could you move
objects from database to database?