On Thu, Mar 5, 2009 at 9:11 PM, David W Levine <dwl@us.ibm.com> wrote:

>
> Jon observes that, with an OGP like approach, you need to have clients
> which are compatible with the set of content, and delivery style shared by
> the regions you wish to connect to.  Yes. Tho, one can observe that the OGP
> documents describe sets of services, and you can  factor and deploy these
> services in a number of ways, which are significantly more flexible than the
> current model used within OpenSim and  SecondLife. If you look at the
> overall set of services described in OGP, it describes a model for signaling
> between simulations  and, to an extent, describes *one* model for
> signaling between clients and simulations.  There is a great deal of room
> for web style content negotiation
> and there is also very little said about what might happen at the client
> side of the experience when handing off between virtual spaces. It would not
> be hard, at all, for the new region to signal to a client 'Here is the type
> of simulator I am, you'll need to handle this"
>
>
I agree, and I would expect the group to be able to analyse the differences
between platforms in that light to find areas in the problem and solution
spaces where interop could be achieved.  Instead, the discussion has taken a
rather strange form, something along the lines of:


*Systems A and B are significantly different in areas X.  Protocol P is
being designed to provide compatibility with system A.  Therefore protocol P
cannot provide compatibility with system B.
*


In the absence of further analysis (which I have not yet seen done
adequately), the above form of argument is flawed on at least two counts:


   1. First of all, providing compatibility with A does not necessarily
   preclude providing compatibility with B --- you have to examine the problem
   carefully and search for solutions before you can give up and assert the
   negative.
   2. And secondly, the negative conclusion presupposes that P is immutable,
   whereas the reality is that P is still being defined and therefore can be
   modified for compatibility with B.


In my opinion, the state of our analysis so far is so minimal that any claim
of non-interoperability is entirely premature.

>From what I've read so far, I believe that there is ample room for
compatibility between the two models in the presence of both content and
signaling diversity, because we have many, very powerful methods at our
disposal:


   - we can search for subsets of direct commonality (which in computing
   systems are *always* present),
   - we can create superset mechanisms that unify incompatible approaches
   (as I did with the two object execution models),
   - we can create mechanisms that are *extensible* to handle content
   diversity,
   - we can use negotiation to select interoperable feature sets out of a
   much larger palette of options,
   - we can use negotiation to switch between entirely different signaling
   methods,


and probably many other methods as well.  We have no shortage of tools to
bear on the problem.

It does of course require a willingness to examine the options and to accept
that significant change will need to be accommodated, on all sides, but that
is presupposed anyway in an IETF group that seeks to create non-proprietary
standards with Internet-wide applicability.

I propose that we examine the perceived differences one at a time to
understand the problem space better (which is appropriate at this stage of
the IETF process anyway), and while acknowledging that there are large gaps
to bridge, that we actually look for ways to bridge them.


Morgaine.








On Thu, Mar 5, 2009 at 9:11 PM, David W Levine <dwl@us.ibm.com> wrote:

>
> So... this is an interesting topic.
>
> Interop, in the large, is clearly bounded by places where various elements
> diverge.  In the current collection of virtual worlds implementations,
> we have model divergence in a huge number of areas. These include what
> types of 3d objects we model, how we manage the distribution of
> state within our worlds, how we off-load various tasks to different parts
> of the computer infrastructure, and a list which covers pretty much
> every design choice possible when assembling a virtual immersive space.
>
> A number of proposals are on the table to bridge various parts of these
> model differences. Each and every one requires some overlap
> in core models to be able to generate interop, and the various existing
> worlds differ enough that they will inhibit using one approach, or another,
> or in some cases, many of the approaches which have been discussed.
>
> Jon observes that, with an OGP like approach, you need to have clients
> which are compatible with the set of content, and delivery style
> shared by the regions you wish to connect to.  Yes. Tho, one can observe
> that the OGP documents describe sets of services, and you can
> factor and deploy these services in a number of ways, which are
> significantly more flexible than the current model used within OpenSim and
> SecondLife. If you look at the overall set of services described in OGP, it
> describes a model for signaling between simulations
> and, to an extent, describes *one* model for signaling between clients and
> simulations.  There is a great deal of room for web style content
> negotiation
> and there is also very little said about what might happen at the client
> side of the experience when handing off between virtual spaces. It would not
> be hard, at all, for the new region to signal to a client 'Here is the type
> of simulator I am, you'll need to handle this"
>
> I observe further, that a great many very successful specifications fall
> very much into this shape. HTTP is used exactly this way throughout the
> web. There is no assurance, whatsoever, that a URL will deliver content
> viewable by all users. In fact, quiet the contrary. We often find a URL
> leads us to an item which cannot be rendered by our browser, because we are
> missing a plug-in, or we don't support a feature, such as ActiveX
> or Javascript. In the web, we may be turned away at the door by an HTTP
> server, if we do not have a matching certificate, or support a certain style
> of
> authentication.
>
> Different approaches at solving model mismatches let us solve different
> sets of problems. None is a panacea. Co-simulating an OpenSim style region
> with rich
> second life style content with an OLIVE region will not let the OLIVE users
> see the content which exploits SL specific affordances on the SL client,
> unless there
> are matching affordances, and a mechanism to express those matches. If
> virtual A uses avatars with skeletons based on one scheme, and they are
> presented by
> that world's client, then users co-simulating in virtual world B, will be
> unable to properly see the avatars, unless, again, the client they are
> running has the ability to present similar
> skeleton based avatars, and the model mismatches are bridged.
>
> Worlds which perform entirely client side physics won't be helped directly
> by cosimuation with worlds which perform entirely host side physics.
>
> Croquet depends on low level capabilities in its t-object model to generate
> certain effects. People wishing to interoperate with such spaces, will have
> to
> bridge into that model.
>
> I think it is premature to say any one model solves more or less problems.
> I know it is premature to say an approach which has not been implemented
> solves
> problems when half an hour of thoughtful consideration raises dozens of
> issues which the approach would have to manage.
>
> I am very supportive of broad, inclusive discussions of these issues. I
> have learned a lot about various approaches in the past week and I look
> forward to learning much more.
>
> - David W. Levine
> ~ Zha Ewry (ISL)
>
>
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox
>
>