Re: [vwrap] one question

[Sean Hennessee <[e-mail]>]

This sounds very much like my video example.

I go to one web page that shows me a video using Flash; if I don't have 
the flash plug-in, I have to download it and install it. I click on a 
link somewhere on that page that takes me to another web page that shows 
me a video using Quicktime; if I don't have the Quicktime plug-in, I 
have to download it and install it. I click on yet another link that 
takes me to yet another page that shows me a video using Real Media; 
when it asks me to download it because I don't have it, I refuse because 
of my desire not to ever use Real Media as a video player. So, I have to 
go back to my previous page or just go somewhere else entirely.

All of these pages could very easily be using my Google login, or 
Facebook login, etc., as a way to identify me to each of these hosting 
sites.

Each of these plug-ins allows me similar or different ways to control 
the video I am watching, i.e. some may allow pause, others may not.)

All of these plug-ins are displaying digitial video. While there are 
different standards for varying formats of digital video, they are each 
being displayed in my browser using the appropriate plug-in.

While it is an oversimplification of doing the same thing with virtual 
worlds, it has enough similarities that we can learn from it.

Peace,
Sean

On 09/24/2010 02:03 PM, Crista Lopes wrote:
> 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.
>
> 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.
>
> 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?

-- 

Sean Hennessee
UC Irvine

... . .- -. /  .... . -. -. . ... ... . .