Re: [mmox] 3-world OGP interop scenario

[Jon Watte <[e-mail]>]

Morgaine wrote:
> I would go further and say that this is even compatible with Jon's 
> models, given a willingness to be flexible.  Current OLIVE clients may 
> not be able to talk to other systems, but this is no bar to new 
> clients of OLIVE being able to do so.
>

So, if no users want to pay money for the convenience of not having to 
install two separate clients, exactly why would any profit-seeking 
company implement a second protocol in their client?
Note that there is significant economic incentive to implement 
server-side interop -- and separately, strong economic incentive to 
*not* implement client interop. In general, standards tend to be adopted 
when they make business sense, and not adopted when they don't.


>
> And there are other solutions as well.  Nothing precludes OLIVE 
> servers from performing the role of a client in an OGP endpoint.  Some 
> detailed analysis of inbuilt assumptions would be required to be sure 
> that this can work, but in principle an OLIVE (or LESS) server could 
> obtain all the necessary data in this way from which to build a local 
> simulation for its clients.

Except that, if I implement OGP today, I get exactly zero available 
interop, because the circuit of other needed protocols is very large. 
Specifically, the only people who can get interop from OGP today is the 
people who already speak the same client protocol, and use the same 
server-side object execution environment -- which means Second Life and 
Open Sim. If you actually expect acceptance from other vendors, and 
actually are interested in interoperating outside that circle, OGP isn't 
the way to go. If you don't care, then of course you'll standardize what 
you already have.

Sincerely,

jw