Re: [mmox] 3-world OGP interop scenario

As a user, I would prefer a client which could connect to multiple services, and I would partially base my decision on which services were desirable to subscribe to by how capable and reusable is the client software they provide. A service may market itself as a compelling experience and provide some incentives to get me to try it out, but if I don't find the service continues to maintain my interest, I will no longer use that service and will likely remove the associated client software from my computer to maintain space for more suitable services. If I need to install new, potentially spyware or malware infested software to try new services, then I consider that a barrier to my trying the service. Likewise I consider having to register a new account, risking my personal information to yet another company, another barrier to entry. While I probably would not be willing to pay extra for a client which could function with multiple worlds, companies that
 allow the use of interop-capable viewer software and some level of credential/authorization sharing stand a greater chance of attracting me as a customer as I could test drive their service with less effort on my part. Likewise, they stand little chance of keeping my business if they cease to provide a compelling experience and the software required to access that service consumes my computing resources without perceived benefit in return.

Experiences such as these suggest that there are additional costs involved for any business which demands a single service capable client and these costs may deserve consideration when attempting to account for the potential profitability of efforts towards interoperability.

Best Regards,
--Tom Hoff

----- Original Message ----
From: Jon Watte <jwatte@gmail.com>
To: Morgaine <morgaine.dinova@googlemail.com>
Cc: MMOX-IETF <mmox@ietf.org>
Sent: Friday, March 13, 2009 6:45:42 PM
Subject: Re: [mmox] 3-world OGP interop scenario

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

_______________________________________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox