Re: [vwrap] one question

["Hurliman, John" <[e-mail]>]

Comments inline.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Crista Lopes
> Sent: Friday, September 24, 2010 2:03 PM
> To: [e-mail]
> Subject: Re: [vwrap] one question
> 
> On 9/24/2010 1:46 PM, Hurliman, John wrote:
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On
> >> Behalf Of Crista Lopes
> >> Sent: Friday, September 24, 2010 1:40 PM
> >> To: [e-mail]
> >> Subject: Re: [vwrap] one question
> >>
> >> On 9/24/2010 1:32 PM, Hurliman, John wrote:
> >>
> >>> For the case of your client talking to your virtual world, you don't
> >>> have to follow any standards at all. That is completely outside the
> >>> scope of VWRAP and no one is going to say "your client is using AJAX
> >>> to fetch assets instead of the VWRAP standard, you're not VWRAP
> >>> compliant!". But if you want your virtual world servers to
> >>> interoperate with other clients that are written by other people
> >>> (and may not be written in Javascript at all) you need to expose
> >>> VWRAP-compliant endpoints on your servers that follow very precise
> >>> specs. Does that clear up the possible disconnect we're having?
> >>>
> >>>
> >> I think the disconnect is not on this conversation, as I completely
> >> agree with you. The disconnect is on things that are written on the drafts.
> >>
> >>
> > But the drafts don't apply to the case of your own client connecting to your
> own server using your own protocol. They don't (or shouldn't, if they do)
> even attempt to address that because it's way outside the interop
> conversation. The charter and drafts should only be talking about how you
> can expose precisely defined endpoints to allow auth/asset
> retrieval/teleporting (and more down the road) from other clients or servers
> that also understand the VWRAP spec. To use the OpenID or OAuth
> example, supporting OpenID logins on your blog does not preclude you from
> also supporting your own non-standard user registration and auth system.
> From an engineering standpoint, it's a thing tacked on to the side of your
> system to allow interop with other systems, it doesn't define your core
> architecture. If the charter or drafts are stating otherwise, please point out
> exactly which phrases in which paragraphs are doing so because they need to
> be corrected before VWRAP will go anywhere.
> >
> >
> I already did on my initial review.
> Let me give an example with as much detail as I can fit in 5 minutes.
> 
> My student  is working on a JavaScript viewer for OpenSim. He is going to
> make a bunch of decisions about how the browser gets the assets.
> These decisions are noone's business. I think we agree.
> 
> Now, you go and develop another Javascript viewer for OpenSim. You are
> going to make a bunch of decisions about how the browser gets the assets,
> and those decisions are completely different from my student's.
> 
> Now, I point my browser to my student's world, I login, and I get the content.
> Great. Next I want to go from my student's world to yours, so some UI
> happens, and I go to your world using my web browser. I also get the
> content, as I get your JavaScript. In terms of interop, your world just needs to
> know who I am (a user of my student's world), and how to get the assets
> related to my avatar. The way that your JavaScript program makes the assets
> of your world come to my browser when I visit doesn't need to be the same
> as the way that my student's JavaScript program makes the assets of his
> world come to my browser when I visited.
> 

In this example, you are defining an interop mechanism that relies on fetching a Javascript blob and executing it to be able to fetch content from another virtual world. That's one possible way of doing virtual world interop, but unfortunately it rules out a large category of clients by using Javascript execution *as your interop mechanism*. You could also do OpenID authentication that way, by just downloading blobs of Javascript that know how to present an authentication UI, phone home, and do their work. Maybe this is how some worlds will interoperate, but it's not VWRAP and it's not in scope.

> Next step: dahlia is developing a Unity3D browser plugin for OpenSim. I want
> to go from your world to dhalia's world. So some UI happens, and I go to her
> world. I need to download the Unity3D web plugin, if I don't have it already,
> and once is installed I also get the content in whichever way dahlia's code
> makes them come the way of my browser. Her world should know who I am,
> and how to get my assets.
> 

This is where the need for a VWRAP protocol comes in; where you can no longer rely on the "execute some opaque Javascript to perform interop" method to communicate identity, assets, and a teleport handshake between two different platforms. Her world should definitely know who you are and how to get your assets, and the way it knows those things is by speaking the VWRAP protocol.

> These are all independently-operated worlds with radically different ways of
> placing the assets in my machine. And yet I ought to be able to visit them all
> while they know who I am and how to render my avatar.
> 
> Is this clear?
> 

Each world has its own protocols and those are out of scope of VWRAP, yet you ought to be able to visit all these different worlds and move identity and assets and presence between them, which is where a precisely defined protocol like VWRAP comes in and says you form a URL just like this and put these exact bits on the wire and you get back this response to complete the exchange. If we're in agreement on that statement then what you said is clear.

John