# ONS

ThwartedEfforts (abakun@scinc.com)
Fri, 2 Aug 1996 09:16:50 PDT

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    >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.