Re: [mmox] 3-world OGP interop scenario

["Mystical Demina" <[e-mail]>]

I think this early in the game I would be surprise we can get the whole
world to agree to one protocol or message format to the degree HTML was able
to achieve.  Also is a more challenging problem and will require a degree of
semantics that hasn't really happened yet in the Internet.  As such I would
believe there will be many protocols and solutions in this space and that it
will take at least 5 or more to start seeing what will be the dominant
solution.  Also I would expect clients to open up and have capability to add
drivers and new features in a way similar to how the browser let's new
capabilities to be implemented.  So the concept of universal browser is
maybe the wrong way to look at it.  It will be more like the client that can
handle the most plug-ins and hacks, hehe.

As such it seems to me the prudent approach is to target the most used and
most popular features first which off hand I think is teleporting, meshing
(mixing data from multiple sources into one virtualization) and data format
support.

Kevin Tweedy
SL: Mystical Demina


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
[e-mail]
Sent: Saturday, March 14, 2009 12:23 AM
To: MMOX-IETF
Subject: 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 <[e-mail]>
To: Morgaine <[e-mail]>
Cc: MMOX-IETF <[e-mail]>
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
[e-mail]
https://www.ietf.org/mailman/listinfo/mmox

_______________________________________________
mmox mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmox