Re: ONS

• Date: Fri, 2 Aug 1996 09:54:26 PDT
• From:
  Quinn <quinn@vv.com>
• Cc: moo-cows@parc.xerox.com
• Content-Type: text/plain; charset="us-ascii"

At 09:16 AM 8/2/96 PDT, ThwartedEfforts wrote:
>>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.

I certainly realize this and, as far as I know, my LambdaMOO duds access
objects not via numbers explicit in the code, but via multi-aliased verbs
which access a property value. 

Regardless, as stated above, the @dump would have explicit object numbers
replaced with their local equivalents (if any), whether they appeared IN
CODE or were indirectly referenced via a PROPERTY VALUE.

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

No argument here wrt caching requests.  In fact, usually the only request
would be made at the time of porting and that to set a property value on the
ported object pointing to the correct local value.  (This does assume the
good programming practice, about which I believe we concur above, of saving
specific objects in property values rather than bare within code.)

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

The ONS would translate only direct objnum->objnum conversions, not $global
references, so the resetting of $clothing would be irrelevant.

Actually, it'd all probably be a pain in the ass anyway.  I was thinking
mainly of a challenging reason to resurrect my old (really old) @grab
MOO->MOO porting mechanism.

La dee da dee da.

Anyway, I agree (if I gleaned your gist), that the main hurdle to porting is
badly designed generics breaking encapsulation.

-Quinn
-probably missing something
-that makes him look like an idiot
-again
-even though he isn't
-really
-i swear
-real big IQ
-dammit

-http://www.bga.com/~quinn/  {PORN!PORN!PORN}

• Prev: ONS
• Next: Re: Out of band (was: builtin prompt support)
• Index: MOO-cows
• Thread: MOO-cows