ONS

• Date: Fri, 2 Aug 1996 09:16:50 PDT
• From:
  ThwartedEfforts <abakun@scinc.com>
• Content-Type: text/plain; charset="us-ascii"

>That would return (as the entity body) the @dumped code for #10108 at
>Ghostwheel (a VR lock interface), with all explicit object numbers (in code
>or property values), replaced with their equivalents (if any), on the
>destination MOO CyberSphere.

All fine and good, but there should never be explicit object numberes in
code.  We wrote a thing a long time ago (which I think we originally swiped
from JH, but I'm not sure) to determine what an object's core reference is.
I'm sure other places have this.  Using this, then before the scipt is
dumped/sent, then in property values, the numbers can be replaced with
references.  We usually do this via $string_utils:print_with_names.

It might also be wise and good to have each MOO keep it's own copy of the
entire namespace (there that term is again!) for other MOOs (caching it,
instead of always making requests to the ONS).  I envision something like:

On E_MOO:
$objects.lambdamoo.quinns_duds = #xxx
$objects.lambdamoo.multiroom = #yyy
$objects.ghostwheel.vr_lock = #zzz
$parser = #122

On Ghostwheel:
$objects.lambdamoo.multiroom = #aaa
$objects.emoo.parser = #bbb
$vr_lock = #10108

On LambdaMOO:
$objects.ghostwheel.vr_lock = #ccc
$objects.emoo.objects.ghostwheel.vr_lock = #ccc

Of course, as you can see, we can end up with multiple references, which is
a bad thing.  This could also be done with the namespaces idea, creating a
name space for each MOO's objects that you have.  Syntax is illrevelant.
You just as well could do:

[lambdamoo]multiroom
[emoo]parser
[ghostwheel]vr_lock

Or something of the sort. (note that the matching stack would have to be
changed to accomadate the new syntax... '@create
$objects.lambdamoo.multiroom named My Multiroom'  or  '@create
[ghostwheel]quinns_duds named hat'.)
But now I'm questioning if this would actually be of value.  Yeah, you could
then reference objects that exist on other MOOs, and via the ONS, dump them
back and forth, but that still doesn't solve the problem of things like 'we
dont like quinn's duds, so we are setting $clothing to what we think if the
best generic clothing).  Core references fall into disuse globally, BUT will
still be considered the be all and end all of locally supported objects.
And the namespace that exists on the local MOO for another MOO should only
contain those objects that have been directly supported.  If anyone was
thinking of doing some kind of distributed database with this idea...  But
what it all comes down to is how things are named/referenced on the local
MOO, and that is pretty much left up to the admins of those MOOs.

• Prev: Re: Non-overrideable verbs
• Next: Re: ONS
• Index: MOO-cows
• Thread: MOO-cows