Re: [mmox] Creating walled gardens considered harmful

[Morgaine <[e-mail]>]

On Sun, Mar 29, 2009 at 6:54 AM, Jon Watte <[e-mail]> wrote:

>
> I think that it's reasonable to believe that the 50 different technologies
> will not each go back and re-implement the entire client/server
> simulation/graphics communication stack.



We're certainly making a protocol suite that all interoperating parties are
expected to implement.  That's our entire purpose here.  However, that does
not mean that all elements of it need to be implemented by everyone ---
that's a local policy decision, and not our call.  We are not really at the
point yet where we can narrow down a "core", because all the elements are
not yet on the table.

It will be a measure of our success or failure to what degree we can
decouple the underlying services, since it is this decoupling plus
flexibility in media handling that will give implementers an effective
design space.  For example, not everyone will want to implement identity
services, or object storage services, or world simulation services.  As we
have already seen in practice, for some parties *interop* will mean no more
than gaining access to avatar data for local 2D projection, so they would
implement only the relevant sections.

With regard to the three elements you mention:


   1. The "client" of the protocol is actually a *client endpoint*, so in
   your context the protocol(s) would have no relevance to your actual clients
   because the *client endpoints* of the protocol would be on your servers.
   2. World simulation is not part of the interop protocol at all, nor can
   it be because every world may implement a completely different simulation.
   On the partially related topic of object behaviour (because this interacts
   with world simulation), I refer you to this discussion on object
models<http://www.ietf.org/mail-archive/web/mmox/current/msg00982.html>
   .
   3. Most graphics would be handled only as extensible media types for
   transport.  For those graphic elements that have associated behaviour,
   subsequently event traffic (ie. telemetry) would also be carried by the
   protocol.  Both avatars and transportable world objects fall into this
   category.


There are many parts to the puzzle, but participants need implement only
those parts of relevance to them.  For example, Limited Capability Clients
that are interested only in text chat would clearly implement only a very
small part of the overall protocol(s).



> Thus, I think that requirement should be placed into the problem space.  Do
> you agree?
>
>
Requirements should definitely be placed in the problem space!  Note however
that requirements are often broad and phrased in incompatible language, and
therefore need decomposition into smaller more tractable elements that are
fully understood before they can be used to synthesize a cohesive protocol.
I've been trying to do that.


Morgaine.








On Sun, Mar 29, 2009 at 6:54 AM, Jon Watte <[e-mail]> wrote:

> Morgaine wrote:
>
>> On Sat, Mar 28, 2009 at 5:18 PM, Jon Watte <[e-mail] <mailto:
>> [e-mail]>> wrote:
>>
>>        The question is: would you want to work on a standard, if you knew
>>    that the standard would only be adopted by 3 out of 50 virtual
>>    world platforms in the world?
>>
>>
>> We're not working on a standard for 3/50.  Instead, we're placing the
>> requirements of the 50 platforms (or as many as we can) into the problem
>> space, and analysing each one separately into components so that we can
>> either find commonalities or else keep the requirements disjoint.  And then,
>> once we see the whole problem space as a set of necessary component
>> requirements, we can finally synthesize solutions that meet 50/50, or at
>> least a high number.
>>
>
> That's great!
>
> I think that it's reasonable to believe that the 50 different technologies
> will not each go back and re-implement the entire client/server
> simulation/graphics communication stack. Thus, I think that requirement
> should be placed into the problem space.
> Do you agree?
>
> Sincerely,
>
> jw
>
>