Re: [mmox] Submission of scope/problem draft as IETF document..

On Thu, Mar 5, 2009 at 10:00 AM, Jesrad <jesrad@gmail.com> wrote:

because there are different existing implementations for the interconnection
> and distribution of parts of the shared simulation, the protocol cannot make
> assumptions about it a priori and must rely on the endpoint for getting a
> reference to another part of the same VW.
>
>
>
Indeed.  A while back I attempted a rough
decomposition<http://www.ietf.org/mail-archive/web/mmox/current/msg00750.html>of
services into functional "Domains" that might be relevant in a
well-connected metaverse, and I came up with a shortlist of 7 Domains.
(OGP currently only has the AD and RD defined, but there may well be more
forthcoming;  this notion is not in any way specific to OGP though.)   There
I assigned terrain and topology services to a notional Geographical Domain,
so in your scenario, there would be no natural adjacency between the regions
of an SL-style 2D grid:  map services would be a duty of the GD, so either
directly or indirectly it would have to be consulted.

However, there's a danger in this kind of decomposition.  Why should we
assume that a VW exposes this kind of information?  It may well use a GD
internally (and other Domains too), but this is entirely separate from the
question of whether it chooses to expose them --- that's a matter of design
policy.  I'll have to check whether the draft OGP hardwires in the design
policy that regions will be exposed, which is an SL implementation detail.
Hopefully it doesn't, so that an OGP system could be implemented using
completely virtualized regions.

These are the kind of questions that we'll be asking when the top level
parts of an interop protocol start to be examined, since policy is not
something that we want to hardwire in accidentally.

Morgaine.

On Thu, Mar 5, 2009 at 10:00 AM, Jesrad <jesrad@gmail.com> wrote:

> I'm not sure my message was clear enough, but that is exactly the
> point I was trying to make: because there are different existing
> implementations for the interconnection and distribution of parts of
> the shared simulation, the protocol cannot make assumptions about it a
> priori and must rely on the endpoint for getting a reference to
> another part of the same VW.
>
> Anyway, I'm glad we completely agree here. I'll try to write more
> clearly from now on.
>
> On Wed, Mar 4, 2009 at 7:29 PM, Jon Watte <jwatte@gmail.com> wrote:
> > Jesrad wrote:
> >>
> >> relying on the endpoint for anything related to it. For example, we
> >> cannot assume that the topological neighbour of a given endpoint is
> >> necessarily the next endpoint to connect to when changing "region", it
> >> must be asked of the current "region". I use the concept of region
> >> (substitute "bubble" or "shard" as you like) here for lack of
> >>
> >
> > Why should interoperability care about implementation details like
> regions
> > or shards?
> >
> > In my mind, those are different for each system. I think it's much better
> if
> > interoperability simply tells us how systems connect together, and agree
> on
> > some shared playbox/space/planet; how each system then contributes
> objects
> > to that shared space is up to that system (within the bounds of
> > interoperability). How the system displays the objects from itself and
> other
> > systems to the clients of that system is also up to that system, entirely
> > separate from interoperability.
> >
> > That would be a lot simpler to implement, at least as a first step, too
> :-)
> >
> > Sincerely,
> >
> > jw
> >
> >
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox
>