Re: [mmox] MMOX: Strawman scope/goals/approach

[Jon Watte <[e-mail]>]

I like the depth of thinking you've put into this. If we can shift the 
overall discussion in this direction, I think that will be very fruitful.


David W Levine wrote:
> 1.        The ability to manage one's identity when interacting in 
> multiple MMOX spaces.

Note that Microsoft tried to do that with Microsoft Passport, for the 2D 
web, where it is a lot easier to do than the 3D web. They didn't 
succeed. It's not yet clear to me that you need an identity, as separate 
from your service provider. After all, if you change mail hosts, your 
e-mail address changes. Thus, I think it would be useful to specify what 
an identity looks like ("an email address is name @ host"), but trying 
to make it so that I can use "[e-mail]" when I sign up for 
HotMail doesn't seem feasible.

>
> 3.        The ability to share content between MMOX spaces
>        a.        Import and Export of content and models (This may 
> well leverage off of
>        existing work such as Collada) Static, import/export of content 
> while not
>        terribly dramatic is an important part of the value chain of 
> interoperability

Offline and online sharing are, I think, very different. For offline 
sharing, you want as rich a model as possible, and size isn't all that 
important. For online sharing, you want something that gives a 
representative visual, but there are a lot of things you don't need 
(such as built-in scripting, undo history, specific modifier stack 
parameters for your DCC, etc).
Also, for offline sharing, there are several official or de facto 
standards already in place, including AutoCad, COLLADA and X3D (which 
attempts to deliver on the "interactivity/scripting" part of a virtual 
world object).

>                ii.        Extensible, with a common registry, so that 
> we can understand the
>                        types of contents a client can accept, and a 
> virtual space, or virtual
>                        asset store can be asked to provide

I believe that if the standard is just an empty vessel, where different 
systems can put different content, then no true interoperability will 
have been achieved, because something like the Source Engine will put in 
Source Engine format data, and something like Club Penguin will put in 
Club Penguin format data. Yes, you can get the data, but that doesn't do 
you any good, because your system can't understand it. Thus, you get a 
lot of "Hey, I'm compliant with standard X!" without any real 
operability coming out of it. I am strongly for specifying a minimum set 
of content types that have to be supported, whatever they are. Ideally, 
that minimum set is something that maps well to existing content 
repositories, including all the AutoCad models of the world's cities and 
buildings, the Google Warehouse, and ESRI GIS data, for example.

> 4.        The affordances in MMOX to permit the creation of 
> micro-payment economies
>        a.        Appropriate spots defined in MMOX protocols for cost 
> information
>        b.        Appropriate spots defined in MMOX protocols for 
> reference to
>                micropayment systems
>

I'm not so sure this is in scope at all. If I want to do a transaction 
with a service provider, I expect that to be done through a web 
application. There are already fine web application standards. If any 
tie into micro-payments is needed, I think that only the capability to 
tie a web link to a command is necessary -- the fact that that 
link/command is a micro-transaction isn't even necessarily known to the 
VW system.

> 5.        The ability to share "non immersive streams" between spaces

Again, assuming we have a content description, that "ability" can be 
expressed as a simple URL link. In fact, a standard like X3D already 
supports that kind of sharing. I think a much more important problem to 
solve is the sharing of real-time data streams.

Also, there seems to be an implicit assumption that "one space" is 
served by "one system." I think that, long term, that will not actually 
scale. You won't put a simulation of 40,000 avatars on Times Square onto 
a single system. You simply must come up with a way to share the 
simulation of those avatars betwene separate systems. Thus, for both 
scalability, and interoperability reasons, I think that the ability for 
two separate hosts to "share responsibility" of an agreed virtual space 
is important. And, once you have that, each user of each of those 
systems can experience that shared space through the already existing 
infrastructure, without any particular user-side presentation standard 
being needed at all.

Sincerely,

jw