Subject: [vwrap] one question

From: Cristina Videira Lopes <[email-masked]>
Date: Wed, 22 Sep 2010 18:47:39 -0700

Let me summarize my main puzzlement with the drafts, and with some of 
the things stated here, with one very simple yes/no question that, 
hopefully, the group will get to a consensus in no time:

I have a student starting to work on a JavaScript+HTML5 viewer for 
brain-dead-simple, multi-user, OpenSimulator-served scenes. I can do 
that very easily with OpenSim, since the client protocol is a plugin. Is 
VWRAP set up to develop protocols for interoperability between virtual 
worlds that, like these ones, use the web browser as the client?
a) Yes
b) No

People's answers?

---

From: Jonathan Freedman <[email-masked]>
Date: Wed, 22 Sep 2010 21:55:16 -0400

Hello,

I would go with a resounding 'yes'. While the language needs some work, the
protocols as they are defined today should be implementable in anything that
provides support for 'web services' (in the most generic sense of the term).
I think modern browsers are arguably at this level today.

Regards,

Jonathan

On Wed, Sep 22, 2010 at 9:47 PM, Cristina Videira Lopes
<[email-masked]>wrote:

> Let me summarize my main puzzlement with the drafts, and with some of the
> things stated here, with one very simple yes/no question that, hopefully,
> the group will get to a consensus in no time:
>
> brain-dead-simple, multi-user, OpenSimulator-served scenes. I can do that
> very easily with OpenSim, since the client protocol is a plugin. Is VWRAP
> set up to develop protocols for interoperability between virtual worlds
> that, like these ones, use the web browser as the client?
> a) Yes
> b) No
>
> People's answers?
>
> _______________________________________________
> vwrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vwrap
>

-- 
Jonathan Freedman
President
Open Metaverse Foundation
+1 (514) 582-1533

---

From: "Hurliman, John" <[email-masked]>
Date: Wed, 22 Sep 2010 19:56:25 -0600

I'll respond with my own perspective and goal. If we standardize the initial set of features I outlined in my previous e-mail, that web browser client would interoperate with any virtual world that supported the particular state synchronization protocol it uses (which I imagine will be WebSocket+JSON based, but VWRAP would not care about nor try to intrude on). One asset server could serve assets to a variety of heterogeneous VWs, one identity server could work across a variety of VWs, but clients would only be able to connect to worlds that they had state sync protocol support for.

I'm definitely open to the possibility of standardizing more things and moving beyond that level of interop, but that's my goal for step one.

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Cristina Videira Lopes
> Sent: Wednesday, September 22, 2010 6:48 PM
> To: [email-masked]
> Subject: [vwrap] one question
>

---

From: Morgaine <[email-masked]>
Date: Thu, 23 Sep 2010 04:01:13 +0100

Crista, the simple answer is *Yes*, but a more accurate answer is that the
question is not really very well posed, because it suggests things about
VWRAP that aren't really applicable.

The *Yes* answer is actually an answer to the question "Is VWRAP a suitable
framework for developing protocols for interoperability between virtual
worlds based on OpenSimulator (or similar).  Sure, that's the idea. :-)))

But in VWRAP, it is immaterial what kind of client application runs the
client endpoint of the VWRAP protocols, so the phrase "virtual worlds that
use the web browser as the client" doesn't really make much sense in our
context.  The answer is *Yes* only because we scratch our heads and then
ignore the phrase as an unnecessary condition.  Sure, why not? :-)))

Admittedly, your student would probably need to do some rather unnatural
coding since the VW model is really quite distant from the Web model, and
Javascript in the browser runs sandboxed so it's an interesting question how
your client would be coaxed to talk to various external services, for
example to be able to see assets worn by visitors from other worlds.
(Remember that VWRAP is not tied to the SL model in which everything is
proxied through the current sim, a highly non-scalable arrangement.)

I think that answers your question from the VWRAP end, but I get the feeling
there's something missing still.  Perhaps I could pose a question of my own
to help the discussion:  Do you consider a "virtual world that uses the web
browser as the client" to be significantly different to a virtual world that
doesn't define the type of client?

I would hope your answer is "No", since otherwise it would suggest that
worlds are going to Balkanize by the clients they use, which of course would
help nobody, and interop would be compromised.

Morgaine.

===========================

---

From: Meadhbh Hamrick <[email-masked]>
Date: Wed, 22 Sep 2010 20:27:03 -0700

yes and no.

VWRAP is set up to develop protocols for service interoperability.

if you choose to deploy these services to render a virtual world, then
the answer is yes. but the protocol specification does not require
endpoints to be user agents.

but you could just as easily use VWRAP to, for instance, control
inworld bots. or you could have a web app that retrieves asset data
directly from an asset service and renders it using WebGL (maybe for
something like xstreetsl.)

but my answers shouldn't be a surprise, since it's clear i like the
term "service level interop."

but the use case you describe: yes. the PROTOCOLs used in the use case
are in scope. other aspects, probably not. we don't want to specify a
single internal virtual world state.

if we build a protocol where the client portion (at least) can't be
rendered with HTML5+WebGL, then i would say we've failed.

also, in the example you give, there's no reason you couldn't have an
app that spoke some VWRAP and spoke some linden legacy protocol and
some <fill in the blank>.

-cheers

--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [email-masked]

---

From: Cristina Videira Lopes <[email-masked]>
Date: Thu, 23 Sep 2010 08:20:33 -0700

Morgaine wrote:
> But in VWRAP, it is immaterial what kind of client application runs 
> the client endpoint of the VWRAP protocols, so the phrase "virtual 
> worlds that use the web browser as the client" doesn't really make 
> much sense in our context.  The answer is *Yes* only because we 
> scratch our heads and then ignore the phrase as an unnecessary 
> condition.  Sure, why not? :-)))

OK. So there are "client endpoints of the VWRAP protocol". Does this 
mean that there are defined behaviors for a VWRAP client on those 
endpoints? In other words, if my viewer is in JavaScript, I have to make 
the JavaScript program do things in specific ways, and not others, in 
order to be able to interoperate in VWRAP?

> Admittedly, your student would probably need to do some rather 
> unnatural coding since the VW model is really quite distant from the 
> Web model, and Javascript in the browser runs sandboxed so it's an 
> interesting question how your client would be coaxed to talk to 
> various external services, for example to be able to see assets worn 
> by visitors from other worlds.  (Remember that VWRAP is not tied to 
> the SL model in which everything is proxied through the current sim, a 
> highly non-scalable arrangement.)
CORS addresses that issue (avoiding the jasonp trick).
But this exposes the point I'm trying to clarify: on the web browser, 
VWRAP seems to be *forcing* application developers to use CORS, instead 
of leaving that as an independent engineering decision of each 
application. Why?

>
> I think that answers your question from the VWRAP end, but I get the 
> feeling there's something missing still.  Perhaps I could pose a 
> question of my own to help the discussion:  Do you consider a "virtual 
> world that uses the web browser as the client" to be significantly 
> different to a virtual world that doesn't define the type of client?
No; I'm interested in virtual worlds that are Web applications -- no 
more, no less. But the VWRAP protocol seems to be defining a specific 
type of client, and hence, a specific way of writing the JavaScript 
program -- at least wrt the endpoints.

>
> I would hope your answer is "No", since otherwise it would suggest 
> that worlds are going to Balkanize by the clients they use, which of 
> course would help nobody, and interop would be compromised.

Agreed.

---

From: David W Levine <[email-masked]>
Date: Thu, 23 Sep 2010 12:23:26 -0400

The very phrase protocol endpoint rather gives the answer. VWRAP describes
how to request things be done, and how data is delivered in response to
those requests. What the requester does with the data is out of scope,
There are descriptions about what the delivered data "means" but, that
merely means
that, just like a web page, if you request a page, parse it and then
generate subsequent requests based on a faulty or confused understanding of
the
delivered data your subsequent requests are likely to be poorly formed, and
generate error replied. Likewise if you request things of a VWRAP service
and build odd requests based on that, the VWRAP service will likely be
confused by those subsequent requests. (And being largely stateless REST
services will
happily say huh in the expected way)

- David
~ Zha

[email-masked] wrote on 09/22/2010 09:47:39 PM:

> From:
>
> Cristina Videira Lopes <[email-masked]>
>
> To:
>
> "[email-masked]" <[email-masked]>
>
> Date:
>
> 09/22/2010 09:48 PM
>
> Subject:
>
> [vwrap] one question
>
> Sent by:
>
> [email-masked]
>

---

From: Boroondas Gupte <[email-masked]>
Date: Thu, 23 Sep 2010 18:38:13 +0200

I'm not up to date with everything here, so I hope I don't get it
completely wrong, but here's my take:

On 09/23/2010 05:20 PM, Cristina Videira Lopes wrote:
> In other words, if my viewer is in JavaScript, I have to make the
> JavaScript program do things in specific ways, and not others, in
Only regarding what they /send/ and /receive/ over the wire when
communicating with VWRAP services, I think. The web analog would be that
to talk to a web server, you have to speak and understand HTTP.
Depending on what server it is and what you'd like to do with it, there
might be additional requirements, e.g. WebDAV (just an arbitrary example
out of many). What you do within the bounds of these protocols and what
other processing you do (including interfacing non-HTTP resources) is
completely up to you.

Likewise, to talk to a VRAP service, you'll have to speak and understand
VWRAP.core and, depending on the kind of service and what you want from
it, the relevant VWRAP.<insert service type here> protocols. What you do
within the bounds of these protocols and what other processing you do
(maybe interfacing non-VWRAP resources) is again up to you.

So the "behavior" of the end point only matters in a black-box way: in
what can be seen from the VWRAP services. Whatever happens inside (or at
the non-VWRAP sides of the box) is out-of-scope for a communication
protocol.

Cheers,
Boroondas

---

From: Meadhbh Hamrick <[email-masked]>
Date: Thu, 23 Sep 2010 10:00:21 -0700

also. VWRAP separates "application data" form the transport it's
carried over (like XMPP, HTTP, websockets) and from the form in which
it's serialized (XML, JSON, Binary).

so if you're in a web browser that can't do websockets, you can speak
HTTP and do long poll. there's no requirement in the protocol
specification that a server support websockets over long poll, but
then again, we didn't explicitly require server deployers from
shooting themselves in the foot either.

when we say things like "mechanism, not policy" one of the policies we
think people will have to decide is what services will be accessed
with which protocols.

earlier participants in this group (*cough*lentzner*cough*) advocated
a hands off approach for doing any sort of content or transport
negotiation and just letting individual service providers work out how
to communicate their transport/content encoding decisions to their
clients.

i'm pretty sure i heard pixelq and jhurliman say they would like to
have (at least) a clear description of how to use HTTP status codes to
communicate issues like preferred content encoding.

but.. i think i'm sort of rambling off topic here..

so let me simply re-iterate... yes.. if you use the VWRAP protocol,
your client is expected to be able to interpret messages it receives
and understand the semantics of the messages it sends.

-cheers
-meadhbh

On Thu, Sep 23, 2010 at 9:38 AM, Boroondas Gupte
<[email-masked]> wrote:
> I'm not up to date with everything here, so I hope I don't get it completely
> wrong, but here's my take:
>
> In other words, if my viewer is in JavaScript, I have to make the JavaScript
> program do things in specific ways, and not others, in order to be able to
> interoperate in VWRAP?
>
> Only regarding what they send and receive over the wire when communicating
> with VWRAP services, I think. The web analog would be that to talk to a web
> server, you have to speak and understand HTTP. Depending on what server it
> is and what you'd like to do with it, there might be additional
> requirements, e.g. WebDAV (just an arbitrary example out of many). What you
> do within the bounds of these protocols and what other processing you do
> (including interfacing non-HTTP resources) is completely up to you.
>
> VWRAP.core and, depending on the kind of service and what you want from it,
> the relevant VWRAP.<insert service type here> protocols. What you do within
> the bounds of these protocols and what other processing you do (maybe
> interfacing non-VWRAP resources) is again up to you.
>
> So the "behavior" of the end point only matters in a black-box way: in what
> can be seen from the VWRAP services. Whatever happens inside (or at the
> non-VWRAP sides of the box) is out-of-scope for a communication protocol.
>
> Cheers,
> Boroondas
>

---

From: Meadhbh Hamrick <[email-masked]>
Date: Thu, 23 Sep 2010 10:33:17 -0700

oh. upon re-reading this, maybe it would be good for me to reiterate
some of the motivations for LLSD/LLIDL (later DSD).

a lot of people think that LLSD is an XML DTD for communicating random
bits to and from Second Life. it's understandable to think that since
that's the most common use we see in the wild. and.. the LLSD drafts
have been a little fuzzy on the motivation behind LLSD. (something i'm
fixing in the next rev.)

LLSD was originally thought of as an "abstract type system." that
means it's purely hypothetical. we used it inside linden to define
data structures in a programming language independent way. it was used
mostly to communicate ideas and data structures between engineers when
we were developing services.

because it was "abstract" it was not supposed to be directly
implemented. rather, in each programming language we used, we would
create a mapping between abstract types in LLSD and "reified" types in
an actual programming language. if you search, you can find python and
c++ implementations in the source code linden open sourced. (and
possibly a PHP implementation, can't remember.)

so, we liked to make service interfaces that were defined using LLSD
because that way we don't accidentally impose type behavior of one
language (C++) on another (python).

when it was time to communicate with these services, we had to
serialize / marshal data structures defined using LLSD into an octet
stream that could go over the network. an early implementation of this
was the "annotation format" which looked remarkably like JSON. then
the people who advocated the annotation format were sacked and we got
some more people who really liked XML. that's where the XML
serialization came from.

some of our web developers and many external peeps commented that the
annotation format was nice 'cause it was so much like JSON and they
really liked JSON. so someone snuck some code into the tree that
serialized/deserialized LLSD into JSON. there was a wailing and
gnashing of teeth because at the time we were drinking too much good
scotch to realize we had better things to worry about.

and somewhere in there someone decided that XML was for "high level
language dweebs" and added the binary serialization. (this actually
isn't really true, but its the story we invented because the truth was
much more boring.)

but the idea here was we felt there were some situations that called
for a binary serialization, some that called for a json serialization
and some that called for an XML serialization. at one point i think
all of second life's external LLSD based interfaces only accepted XML,
but the plan was always to eventually getting around to making them
serialization independent whenever we opened up an OGP compliant grid.

XML vs. JSON vs. Binary was still a minor subject of debate when i was
at the lab, but i think everyone was on board with the idea that if we
had a real-live 'open' interface, we would "do the right thing" and
support all serializations, OR, publish a big note somewhere that said
"if you deal with us, you give us XML."

when we specified LLSD and LLIDL, our believe was that peeps who
exposed LLSD/LLIDL based services would, on an endpoint by endpoint
basis, decide which serialization and transport (HTTP, HTTPS, XMPP or
websockets) was the best choice for their application. that's the
basis, i believe, of mark lentczner's desire to not define a content
negotiation strategy since it might limit the service provider's
freedom in deciding it would only support a single transport or
serialization.

my experience in implementing OGP on the vaak test grid was that our
partners were actually very interested in content negotiation for
LLSD/LLIDL messages over HTTP(S) at least.

so... that's going to show up in the next rev of the type system draft
i'm writing.

so wrapping this thread up and going back to Diva's use case... the
current understanding of VWRAP is that there will be RESTful resources
at the end of HTTP(S) (and possibly XMPP) endpoints. the interface for
these resources will be defined using something like LLSD or DSD (DSD
is the next generation of LLSD. it's a few minor changes and it
removes the "LL" 'cause i wanted a MIME type that was distinct from
LLSD's.) the content of messages to and from these endpoints would be
serialized using the XML, JSON or Binary serialization schemes (aka
transport syntaxes.)

if your JavaScript app is talking to a service that it knows only
supports one of these serialization schemes, then there's no need for
it to support the others. if the server you're talking to only accepts
requests from clients that only make requests in specific schemes,
then there's no need for it to support the others.

but in the real world, we're probably going to see a lot of people use
BOTH JSON and XML. i'm guessing Binary will be more likely to be seen
between hosts in tightly coupled clusters of servers. but heck, i
could be wrong.

so the safe thing to do is for clients to send requests using
serialization schemes they like to generate and ask for responses in
serialization schemes they like to parse. server coders should suck it
up and cope with the fact that it's a diverse world out there and
arguing about XML vs. JSON vs. Binary encoding is just not productive.

or not. because... in this protocol, we specify mechanism, not policy.

-cheers
-meadhbh

p.s. - but if you're in control of both the server and client, then
yeah, just pick whichever serialization scheme you want to use.
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [email-masked]

---

From: Crista Lopes <[email-masked]>
Date: Thu, 23 Sep 2010 10:48:16 -0700

On 9/23/2010 9:38 AM, Boroondas Gupte wrote:
> communicating with VWRAP services, I think. The web analog would be 
> that to talk to a web server, you have to speak and understand HTTP. 
> Depending on what server it is and what you'd like to do with it, 
> there might be additional requirements, e.g. WebDAV (just an arbitrary 
> example out of many). What you do within the bounds of these protocols 
> and what other processing you do (including interfacing non-HTTP 
> resources) is completely up to you.

*According to the drafts*, VWRAP seems to be prescribing specific ways 
of doing the initial user sign in, and specific ways of placing the 
asset data in the user's machine. For sign in, and ignoring what seems 
irrelevant prescriptions that I'm sure will be eliminated, it seems that 
the client must get a seed capability that it then invokes to get more 
capabilities; for asset data, it seems that the VWRAP presciption is to 
make the server send asset capabilities to the client, and then have the 
client invoke those capabilities.

In other words, it looks like my JavaScript program is not going to be 
VWRAP-compliant, and it won't be able to interoperate, if I don't send a 
seed capability from the server to the client at login,  and if I send 
the assets in any way other than via capabilities that the client then 
invokes (for example, sending assets via WebSockets is not 
VWRAP-compliant (never mind whether it's a good idea or not!)). I'm not 
entirely sure how the asset capabilities model maps to VWs that will be 
streamed.

I'm just trying to understand if this is the case or not, as I work with 
my student on the JavaScript viewer.

>
> Likewise, to talk to a VRAP service, you'll have to speak and 
> understand VWRAP.core and, depending on the kind of service and what 
> you want from it, the relevant VWRAP.<insert service type here> 
> protocols. What you do within the bounds of these protocols and what 
> other processing you do (maybe interfacing non-VWRAP resources) is 
> again up to you.
>
> what can be seen from the VWRAP services. Whatever happens inside (or 
> at the non-VWRAP sides of the box) is out-of-scope for a communication 
> protocol.
>
> Cheers,
> Boroondas
>
>

---

From: Morgaine <[email-masked]>
Date: Thu, 23 Sep 2010 18:53:11 +0100

On Thu, Sep 23, 2010 at 4:20 PM, Cristina Videira Lopes
<[email-masked]>wrote:

> feeling there's something missing still.  Perhaps I could pose a question of
> my own to help the discussion:  Do you consider a "virtual world that uses
> the web browser as the client" to be significantly different to a virtual
> world that doesn't define the type of client?
>
> No; I'm interested in virtual worlds that are Web applications -- no more,
> no less. But the VWRAP protocol seems to be defining a specific type of
> client, and hence, a specific way of writing the JavaScript program -- at
> least wrt the endpoints.
>
>
To some extent, this embroils us in issues of direction and philosophy.
Some people say "We're trying to build the 3D Web", but they're completely
wrong, mistaking an analogy (how the Web is structured and how it exploded
in popularity) with the direction (to create a metaverse of some kind).
Sure, we hope that it'll be as large and as popular as the Web, or even more
popular, but that doesn't mean that the goal is in any way related to the
Web.

In matters of technology, we're trying to use as much Web tech as we can,
but again, that's not because virtual worlds have any actual relationship to
the Web.  It just means that we're sensibly trying to ride on the shoulders
of giants, reaping the benefits of very efficient (and cheap) Web
infrastructure.  When we link VWs to Web content, that's just because people
need their Web-side data or want to harness Web-side functionality, and it
would make no sense at all to deny them access to that from within VWs.

But again, that Web access has nothing to do with virtual worlds being in
any way related to the Web, they're not.  Indeed, they're not even Web apps,
they're Internet apps, and there's a significant difference.  (The
difference is in the data and comms models, more than merely the use of
particular protocols or ports.  IRC isn't a web app either, despite having
gateways on the Web.)

Which brings us to the thorniest issue of the lot, the client.  Browsers are
made for browsing the Web, and if at all possible one should not be trying
to bang in screws with a hammer.  If browser fans insist on using a tool
designed for a different purpose to access VWs, fine, it's their choice, but
it's also their problem if they find that it's not a natural fit.  Perhaps
they can adapt browser technology to fit better, and that would be cool, but
that task is theirs.  They shouldn't expect the very different semantics of
virtual worlds to be restricted to fit into the much narrower pigeon hole of
Web applications.

Morgaine.

==============================

On Thu, Sep 23, 2010 at 4:20 PM, Cristina Videira Lopes
<[email-masked]>wrote:

> OK. So there are "client endpoints of the VWRAP protocol". Does this mean
> that there are defined behaviors for a VWRAP client on those endpoints? In
> other words, if my viewer is in JavaScript, I have to make the JavaScript
> But this exposes the point I'm trying to clarify: on the web browser, VWRAP
> seems to be *forcing* application developers to use CORS, instead of leaving
> that as an independent engineering decision of each application. Why?
>
>
>
> feeling there's something missing still.  Perhaps I could pose a question of
> my own to help the discussion:  Do you consider a "virtual world that uses
> the web browser as the client" to be significantly different to a virtual
> world that doesn't define the type of client?
>
> No; I'm interested in virtual worlds that are Web applications -- no more,
> no less. But the VWRAP protocol seems to be defining a specific type of
> client, and hence, a specific way of writing the JavaScript program -- at
> least wrt the endpoints.
>
>
>

---

From: Meadhbh Hamrick <[email-masked]>
Date: Thu, 23 Sep 2010 11:11:21 -0700

the great thing about standards is there are so many to choose from.

if you want to use the asset and teleport portions of VWRAP without
the seed cap part, go for it.

it's not up to the protocol designers to decide how you wish to deploy
your virtual world services. but clearly if you want to interoperate
with someone who IS using the VWRAP Service Establishment pattern,
you'll have to follow that draft.

this is part of the "we define mechanism, not policy" mantra.

-cheers
-meadhbh

On Thu, Sep 23, 2010 at 10:48 AM, Crista Lopes <[email-masked]> wrote:
> *According to the drafts*, VWRAP seems to be prescribing specific ways of
> doing the initial user sign in, and specific ways of placing the asset data
> in the user's machine. For sign in, and ignoring what seems irrelevant
> prescriptions that I'm sure will be eliminated, it seems that the client
> must get a seed capability that it then invokes to get more capabilities;
> for asset data, it seems that the VWRAP presciption is to make the server
> send asset capabilities to the client, and then have the client invoke those
> capabilities.
>
> seed capability from the server to the client at login,  and if I send the
> assets in any way other than via capabilities that the client then invokes
> (for example, sending assets via WebSockets is not VWRAP-compliant (never
> mind whether it's a good idea or not!)). I'm not entirely sure how the asset
> capabilities model maps to VWs that will be streamed.
>
> I'm just trying to understand if this is the case or not, as I work with my
> student on the JavaScript viewer.
>
>
>
>

---

From: <[email-masked]>
Date: Thu, 23 Sep 2010 14:38:14 -0400

Well, take a look at this and tell me that web, internet, and virtual worlds
aren't all converging and to try to say they are separate and browser are
being used in the wrong way.

http://robotduck.wordpress.com/2010/09/11/hometown-gp-launched/

K.

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Morgaine
Sent: Thursday, September 23, 2010 1:53 PM
To: [email-masked]
Subject: Re: [vwrap] one question

On Thu, Sep 23, 2010 at 4:20 PM, Cristina Videira Lopes <[email-masked]>
wrote:

Morgaine.

On Thu, Sep 23, 2010 at 4:20 PM, Cristina Videira Lopes <[email-masked]>
wrote:

Morgaine wrote: 

context.  The answer is Yes only because we scratch our heads and then

Agreed.

---

From: <[email-masked]>
Date: Thu, 23 Sep 2010 14:49:42 -0400

Why is number of people an issue?

Why does having a server mean it is a virtual world in a browser?

I guess this group is too set into the SL model of things and I will stop
participating.

Thank you.

-----Original Message-----
From: Meadhbh Hamrick [mailto:[email-masked]] 
Sent: Thursday, September 23, 2010 2:42 PM
To: [email-masked]
Subject: Re: [vwrap] one question

yes. it's a great mashup. but it's doesn't meet the VWRAP definition
of a "virtual world" because you only have one person in it: you.

when you can race with other people at the same time, then we've got
something.

also, i'm guessing that there is a server component to this app, so
it's not a "virtual world in a browser" it may be a client capable of
rendering a virtual experience, but that's not what this group is
focused on.

On Thu, Sep 23, 2010 at 11:38 AM,  <[email-masked]> wrote:
> aren’t all converging and to try to say they are separate and browser are
> ________________________________
>
<[email-masked]>
> I think that answers your question from the VWRAP end, but I get the
feeling
> virtual worlds to be restricted to fit into the much narrower pigeon hole
of
<[email-masked]>
> But this exposes the point I'm trying to clarify: on the web browser,
VWRAP
> I think that answers your question from the VWRAP end, but I get the
feeling

---

From: Mike Dickson <[email-masked]>
Date: Thu, 23 Sep 2010 15:00:28 -0400

On 09/23/2010 02:38 PM, [email-masked] wrote:
>
> Well, take a look at this and tell me that web, internet, and virtual 
> worlds aren’t all converging and to try to say they are separate and 
> browser are being used in the wrong way.
>
This is simply using the web to launch into a proprietary environment 
not a use of we bbased technologies.  I say that because I was unable 
using my fully web compliant browser (on Linux) to play the game.

I'm not saying this is wrong. It's one use, one type of client 
endpoint.  An interesting one but certainly not the only one.   This is 
all consistent with past messages that said we're leveraging web 
technologies where they fit but virtual worlds does not == the web.

Mike

> ------------------------------------------------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Morgaine
> *Sent:* Thursday, September 23, 2010 1:53 PM
> *To:* [email-masked]
> *Subject:* Re: [vwrap] one question
>
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>> question of my own to help the discussion:  Do you consider a 
>> "virtual world that uses the web browser as the client" to be 
>> significantly different to a virtual world that doesn't define the 
>> type of client?
>>
> To some extent, this embroils us in issues of direction and 
> philosophy.  Some people say "We're trying to build the 3D Web", but 
> they're completely wrong, mistaking an analogy (how the Web is 
> structured and how it exploded in popularity) with the direction (to 
> create a metaverse of some kind).  Sure, we hope that it'll be as 
> large and as popular as the Web, or even more popular, but that 
> doesn't mean that the goal is in any way related to the Web.
>
> In matters of technology, we're trying to use as much Web tech as we 
> can, but again, that's not because virtual worlds have any actual 
> relationship to the Web.  It just means that we're sensibly trying to 
> ride on the shoulders of giants, reaping the benefits of very 
> efficient (and cheap) Web infrastructure.  When we link VWs to Web 
> content, that's just because people need their Web-side data or want 
> to harness Web-side functionality, and it would make no sense at all 
> to deny them access to that from within VWs.
>
> But again, that Web access has nothing to do with virtual worlds being 
> in any way related to the Web, they're not.  Indeed, they're not even 
> Web apps, they're Internet apps, and there's a significant 
> difference.  (The difference is in the data and comms models, more 
> than merely the use of particular protocols or ports.  IRC isn't a web 
> app either, despite having gateways on the Web.)
>
> Which brings us to the thorniest issue of the lot, the client.  
> Browsers are made for browsing the Web, and if at all possible one 
> should not be trying to bang in screws with a hammer.  If browser fans 
> insist on using a tool designed for a different purpose to access VWs, 
> fine, it's their choice, but it's also their problem if they find that 
> it's not a natural fit.  Perhaps they can adapt browser technology to 
> fit better, and that would be cool, but that task is theirs.  They 
> shouldn't expect the very different semantics of virtual worlds to be 
> restricted to fit into the much narrower pigeon hole of Web applications.
>
>
> Morgaine.
>
>
>
>
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> Morgaine wrote:
>
> endpoints? In other words, if my viewer is in JavaScript, I have to 
> make the JavaScript program do things in specific ways, and not 
> others, in order to be able to interoperate in VWRAP?
>
>
>
>
> VWRAP seems to be *forcing* application developers to use CORS, 
> instead of leaving that as an independent engineering decision of each 
> application. Why?
>
>
>
>
>

---

From: Crista Lopes <[email-masked]>
Date: Thu, 23 Sep 2010 12:21:52 -0700

> this is part of the "we define mechanism, not policy" mantra.

This statement is true for phat clients; it is false for the web 
browser, because for the web browser some of these "standard-compliant" 
mechanisms are intrusions into policy and engineering design -- and 
irrelevant for interop, as far as I can tell. The standard, for web 
browsers, should be agnostic on these mechanisms. Putting an asset in 
the user's machine by pulling or pushing is irrelevant, each world can 
do it in whichever way it wants, and it will all work.

So the drafts need to say: "if you have a client whose viewer is fixed, 
then here are the standards necessary for interop; if you have a client 
that takes the viewer dynamically, then these mechanisms are not 
necessary for interop." Or else say, right upfront: "these standards are 
for clients whose viewer is fixed; they are implementation 
recommendations for clients with dynamic viewers based on... good 
practices(?)"

---

From: Meadhbh Hamrick <[email-masked]>
Date: Thu, 23 Sep 2010 12:30:22 -0700

what?

i have no idea what point you're making here. if you have a thin(ish)
client that you load from a web server, it's still going to talk to
servers out there somewhere. with CORS you can get around the problem
of javascript only being able to talk to the server it was served
from. thin clients talk to servers the same way fat clients do. some
thin clients may decide to break up the task between the web client
and a server proxy (i'm looking into this right now because WebGL
doesn't have a retained mode.) but in that case, the proxy would be
the client to the asset server and speak some custom protocol between
the proxy and the web client.

so why does it matter one whit if the client code was a recently
downloaded bundle of javascript or a honkin big fat client like the SL
viewer?

i'm totally not following you here.

-cheers
-meadhbh

On Thu, Sep 23, 2010 at 12:21 PM, Crista Lopes <[email-masked]> wrote:
> This statement is true for phat clients; it is false for the web browser,
> because for the web browser some of these "standard-compliant" mechanisms
> are intrusions into policy and engineering design -- and irrelevant for
> interop, as far as I can tell. The standard, for web browsers, should be
> agnostic on these mechanisms. Putting an asset in the user's machine by
> pulling or pushing is irrelevant, each world can do it in whichever way it
> wants, and it will all work.
>
> So the drafts need to say: "if you have a client whose viewer is fixed, then
> here are the standards necessary for interop; if you have a client that
> takes the viewer dynamically, then these mechanisms are not necessary for
> interop." Or else say, right upfront: "these standards are for clients whose
> viewer is fixed; they are implementation recommendations for clients with
> dynamic viewers based on... good practices(?)"
>
>

---

From: Morgaine <[email-masked]>
Date: Thu, 23 Sep 2010 20:34:38 +0100

Kevin, that's a pretty nice application, but your subsequent comments don't
follow.

The Web is continually expanding in extent, application and in capability,
but don't mistake *interfacing* for *convergence*.  As an example, IRC and
the Web are not converging either, it's just that the Web has developed
interface portals to IRC networks.  The IRC system is not about to modify
its protocols and networks just because Web fans insist on using Web
browsers to access IRC.  What we're seeing is the growth of interfaces on
the Web, not convergence of the systems themselves.  To a user these two
things might appear to be one and the same thing, but that's an illusion.
As techs we can look into the systems directly, and so we know that they're
not converging at all.

Regarding VWs and the Web "being separate", well they are separate.  They're
not **isolated** from each other because they interact, but they are
certainly separate.  They have distinct identities, very different
semantics, and VWs have many more degrees of freedom and hence far greater
potential capability.  And again, don't confuse interfaces with convergence
--- just because people give the Web some interfaces to VWs doesn't mean
that the semantics of the Web are going to change.

Your final point was "being used in the wrong way".  Well I never said
"wrong", I just said that some tools are not a natural fit for some
problems.  The Web browser is a natural fit for browsing the Web, but that
doesn't mean that it's a natural fit for accessing all digital
technologies.  It's actually an extremely poor tool for some things, for
example UIs.

The classic recent example of this was the dreadful Web interface to Google
Wave, one of the most powerful technologies of recent times but placed in a
straightjacket by the terribly limited UI capability of the browser.  Web
tech will improve in this area of course, and HTML5 certainly holds much
promise, but browser-based UIs have 20 years of lost Human Interface power
and ergonomics to make up first.

Morgaine.

On Thu, Sep 23, 2010 at 7:38 PM, <[email-masked]> wrote:

> worlds aren’t all converging and to try to say they are separate and browser
> are being used in the wrong way.
>
>
>
>  ------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Morgaine
> more, no less. But the VWRAP protocol seems to be defining a specific type
> of client, and hence, a specific way of writing the JavaScript program -- at
> least wrt the endpoints.
>
>
>
>
> Which brings us to the thorniest issue of the lot, the client.  Browsers
> are made for browsing the Web, and if at all possible one should not be
> trying to bang in screws with a hammer.  If browser fans insist on using a
> tool designed for a different purpose to access VWs, fine, it's their
> choice, but it's also their problem if they find that it's not a natural
> fit.  Perhaps they can adapt browser technology to fit better, and that
> would be cool, but that task is theirs.  They shouldn't expect the very
> different semantics of virtual worlds to be restricted to fit into the much
> narrower pigeon hole of Web applications.
>
>
> Morgaine.
>
>
>
>

---

From: <[email-masked]>
Date: Thu, 23 Sep 2010 15:39:28 -0400

Well, obviously from your statements I have a total different philosophy to
the virtual of virtual worlds.

Thank you for your comments.

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Morgaine
Sent: Thursday, September 23, 2010 3:35 PM
To: [email-masked]
Subject: Re: [vwrap] one question

The Web is continually expanding in extent, application and in capability,
but don't mistake interfacing for convergence.  As an example, IRC and the
Web are not converging either, it's just that the Web has developed
interface portals to IRC networks.  The IRC system is not about to modify
its protocols and networks just because Web fans insist on using Web
browsers to access IRC.  What we're seeing is the growth of interfaces on
the Web, not convergence of the systems themselves.  To a user these two
things might appear to be one and the same thing, but that's an illusion.
As techs we can look into the systems directly, and so we know that they're
not converging at all.

Regarding VWs and the Web "being separate", well they are separate.  They're
not *isolated* from each other because they interact, but they are certainly
separate.  They have distinct identities, very different semantics, and VWs
have many more degrees of freedom and hence far greater potential
capability.  And again, don't confuse interfaces with convergence --- just
because people give the Web some interfaces to VWs doesn't mean that the
semantics of the Web are going to change.

Your final point was "being used in the wrong way".  Well I never said
"wrong", I just said that some tools are not a natural fit for some
problems.  The Web browser is a natural fit for browsing the Web, but that
doesn't mean that it's a natural fit for accessing all digital technologies.
It's actually an extremely poor tool for some things, for example UIs.

Morgaine.

K.

  _____  

Morgaine.

Morgaine wrote: 

Agreed.

---

From: Crista Lopes <[email-masked]>
Date: Thu, 23 Sep 2010 12:40:33 -0700

You can do a client pull with JavaScript -- great!, now we can have 
VWRAP JS viewers. But you can also do a server push. And you can do all 
sorts of other things to get the assets on the user's machine. You may 
even not have assets at all -- it may all just be video streaming.

As you point your browser to different VWs on the Web, you get those 
VWs' own viewers, and it doesn't matter that they all do it in the same 
way. The way they choose to do it is an internal engineering decision.

For interoperability of VWs *on the Web*, the only thing you need is a 
shared understanding of user's identity, simulation state, and 
associated assets. Everything else is irrelevant.

On 9/23/2010 12:30 PM, Meadhbh Hamrick wrote:
> On Thu, Sep 23, 2010 at 12:21 PM, Crista Lopes<[email-masked]>  wrote:
>

---

From: Crista Lopes <[email-masked]>
Date: Thu, 23 Sep 2010 12:52:20 -0700

On 9/23/2010 12:34 PM, Morgaine wrote:
> Regarding VWs and the Web "being separate", well they are separate.  
> They're not **isolated** from each other because they interact, but 
> they are certainly separate.  They have distinct identities, very 
> different semantics, and VWs have many more degrees of freedom and 
> hence far greater potential capability.  And again, don't confuse 
> interfaces with convergence --- just because people give the Web some 
> interfaces to VWs doesn't mean that the semantics of the Web are going 
> to change.

OK, this pretty much nails it, Morgaine, thanks for the clarification :)
VWRAP is not about interoperability of web browser -based virtual 
worlds, because they aren't considered here to be "virtual worlds."
Finally!

My use case for VWs is the Web, so now that I know the scope of VWRAP 
doesn't include the Web, I can be a more effective participant.

---

From: Morgaine <[email-masked]>
Date: Thu, 23 Sep 2010 21:09:29 +0100

The "protocols perspective" on this is simply that what's behind a protocol
endpoint is a black box.  Defining a protocol on the understanding that the
endpoint will be running in some specific constrained environment is very
limiting on all other users who don't have those constraints.

In practice what I'm sure will happen is that Web technology will mature to
become as flexible and as capable as standalone technology, but we're quite
far from that ideal at present.  By the time we're finished, perhaps Web
technology will have caught up, but one should always design future systems
with a view to tomorrow's capability otherwise they'll be obsolete before
one's finished.

Morgaine.

==========================

On Thu, Sep 23, 2010 at 8:21 PM, Crista Lopes <[email-masked]> wrote:

> then here are the standards necessary for interop; if you have a client that

---

From: Morgaine <[email-masked]>
Date: Thu, 23 Sep 2010 21:22:19 +0100

Well it goes without saying that VWs were never conceived as being Web apps,
that would have beeen horribly limiting.  That is a recent affectation, and
VWs have a long history that far predates the Web.

However, I think that your statement "*web browser-based virtual worlds ...
aren't considered here to be 'virtual worlds'*" (and please note that this
is *YOUR* statement, nobody else has said it) is too strong.  From my
perspective they definitely are virtual worlds, albeit self-limited by their
choice of protocol technology and interface.

Morgaine.

====================

On Thu, Sep 23, 2010 at 8:52 PM, Crista Lopes <[email-masked]> wrote:

> They're not **isolated** from each other because they interact, but they
> are certainly separate.  They have distinct identities, very different
> VWRAP is not about interoperability of web browser -based virtual worlds,
> because they aren't considered here to be "virtual worlds."
> Finally!
>

---

From: David W Levine <[email-masked]>
Date: Thu, 23 Sep 2010 17:02:05 -0400

I don't think that anyone has said that.. The whole point of the careful
separation of concerns, content negotiation styles and explicitly defining
VWRAP as a set of
protocol end points says just the opposite. I think the only point which
has been repeatedly made is that there are issues of technical maturity.
There is a fair bit of
push back to the idea that a virtual shared space is "merely" or "just" a
type of web page, with an emphasis on the phrase page. This is because
there are some
basic things about a highly visual shared experience which are pretty
different from the typical web 1 or even (and I hate the phrase) web 2 web
page.

A web based client is just another client. If it is rich enough to accept
the content and render it effectively, its a client. I don't think anyone
would say otherwise.
Where the services used to host a virtual reside is also not of interest.
Any environment which can serve up the content can host a VWRAP service. If
you look at the mailing list and some of the drafts which have been
submitted and some of the presentations you will see discussions about how
to deal with resources hosted in a variety of ways. There's also been a lot
of discussion on how the design pattern is effectively a facade intended to
avoid any external need to understand how a service is deployed.

VWRAP has made a distinction that for a given virtual space there is a URI
addressable place in the web which holds the "state" of the virtual space.
This does stand
in distinction to some of the peer to peer co-simulation designs. There was
also some very cogent discussion about how to bridge those models.

- David
~ Zha

[email-masked] wrote on 09/23/2010 03:52:20 PM:

> From:
>
> Crista Lopes <[email-masked]>
>
> To:
>
> [email-masked]
>
> Date:
>
> 09/23/2010 03:54 PM
>
> Subject:
>
> Re: [vwrap] one question
>
> Sent by:
>
> [email-masked]
>
> They're not *isolated* from each other because they interact, but
> interfaces with convergence --- just because people give the Web
> some interfaces to VWs doesn't mean that the semantics of the Web
> are going to change.
>
> My use case for VWs is the Web, so now that I know the scope of
> VWRAP doesn't include the Web, I can be a more effective participant.

---

From: David W Levine <[email-masked]>
Date: Thu, 23 Sep 2010 17:13:17 -0400

As we bash around terms and flexibility and scope, once again. I want to
very gently raise one important cautionary thought, one I think very much
in line with
John's desire to start simple. There is an inherent tension between
flexibility and utility. The more things which can be negotiated and built
in ways which allow
parallel implementations of the same function, the greater the possibility
of creating two totally compliant implementations which can't interoperate
in any useful fashion.

Given the fact that virtual words are, at the end of the day about multiple
people seeing as close the same experience as possible, I think this is an
important point to keep in mind. We all share a desire to build a flexible,
extensible standard. But there are plenty of standards which don't actually
produce interoperability because so much is optional. No specific thing
being discussed here seems bad or out of place, but I do think it useful to
remind ourselves that there are traps at both ends of the spectrum.
Standards which are too narrow fail because they don't meet people's need
for features. Standards which are too broad fail because they don't
actually define enough things to ensure that complaint implementations can
do useful things. For virtual worlds, I strongly believe this trap lurks
more in "what we can display" then in how we move it, but it still does
matter.

Food for thought.

- David
~ Zha

---

From: Sean Hennessee <[email-masked]>
Date: Thu, 23 Sep 2010 15:00:29 -0700

I think this can be compared to the early web and video streaming. Long 
ago no one would seriously consider adding video streaming to a web 
browser since it would clearly be very limited by technology, (internet 
speeds, computing power, and web interface limitations). But all those 
improved over time; now we have HD 1080p video easily being streamed to 
a web browser and controlled by a large portion of the population. (As 
well as having separate stand-alone applications that display streaming 
video over the internet.) Is there a video access protocol that is 
common to all? Some are Flash; some are Quicktime; some are Real Media; 
some are just mpeg. Most of them do use common formats for the original 
video, but differ in how they stream it. Perhaps VWRAP should be about 
defining how to define what is in a virtual world, (making it expandable 
as it is likely to be anyway), and let the implementers figure out how 
best to "stream" and "control" it.

Peace,
Sean

On 09/23/2010 01:22 PM, Morgaine wrote:
> Well it goes without saying that VWs were never conceived as being Web
> apps, that would have beeen horribly limiting.  That is a recent
> affectation, and VWs have a long history that far predates the Web.
>
> However, I think that your statement "*web browser-based virtual worlds
> ... aren't considered here to be 'virtual worlds'*" (and please note
> that this is */YOUR/* statement, nobody else has said it) is too
> strong.  From my perspective they definitely are virtual worlds, albeit
> self-limited by their choice of protocol technology and interface.
>
>
> Morgaine.
>
>
>
> ====================
>
> On Thu, Sep 23, 2010 at 8:52 PM, Crista Lopes <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>>     Regarding VWs and the Web "being separate", well they are
>>     separate.  They're not **isolated** from each other because they
>>     interact, but they are certainly separate.  They have distinct
>>     identities, very different semantics, and VWs have many more
>>     degrees of freedom and hence far greater potential capability.
>>     And again, don't confuse interfaces with convergence --- just
>>     because people give the Web some interfaces to VWs doesn't mean

-- 

Sean Hennessee
UC Irvine

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

---

From: Meadhbh Hamrick <[email-masked]>
Date: Thu, 23 Sep 2010 15:04:51 -0700

> VWs have a long history that far predates the Web.

that's a very interesting point, morgaine. depending on your
definition of "virtual world" you could go back a long way... maze war
on PLATO was the first thing i saw that had the "feeling" of a virtual
world.

and maybe a maze war clone where your eyeball avatar can pick up and
drop objects, rendered via WebGL would make a great, simple demo of
bits of protocol under consideration here.

-cheers
-meadhbh

---

From: Morgaine <[email-masked]>
Date: Fri, 24 Sep 2010 06:42:10 +0100

On Thu, Sep 23, 2010 at 11:04 PM, Meadhbh Hamrick <[email-masked]>wrote:

> *definition of "virtual world"* you could go back a long way... maze war

It certainly looks like a virtual world to me, judging by this video of Maze
War on a Xerox Alto:  http://www.youtube.com/watch?v=7chDIySXK2Q which is
from the same era.

Let's check it against my "*Definition of 'Virtual World', in a protocols
context*" from
http://www.ietf.org/mail-archive/web/vwrap/current/msg00319.html -- the
first sentence gave the definition, without reference to interop:

*For the narrow purpose of describing interoperability protocols for Virtual
Worlds, a Virtual World is defined as a perceptual mashup depicting media
elements located within a single virtual place based on data received by a
client application.*

Check list:

   - "perceptual mashup" -- Yes: the illusion is assembled in our minds.
   - "depicting" -- Yes: a picture or representation is being generated.
   - "media elements" -- Yes: the lines that depict walls, the eyes, and
   map.
   - "single virtual place" -- Yes: a single place, virtual, two
   perspectives.
   - "based on data received by a client application" -- Yes: very
   precisely.

My conclusions:

   1. Maze War constitutes perfect *prior art* for the concept of Virtual
   Worlds;
   2. The *perceptual mashup* definition of VW is robust to evolving
   technology.

Morgaine.

====================================

On Thu, Sep 23, 2010 at 11:04 PM, Meadhbh Hamrick <[email-masked]>wrote:

> apps,

---

From: Cristina Videira Lopes <[email-masked]>
Date: Fri, 24 Sep 2010 08:12:53 -0700

Let me go back to my original comments by reposting my original 
question: "Is VWRAP set up to develop protocols for interoperability 
between virtual worlds that, like these ones, use the web browser as the 
client?" John and Jonathan answered yes. Morgaine, Meadhbh and David 
gave ambiguous answers somewhere between yes and no.

The answer to this question cannot be ambiguous, for the following reason.

It has been stated here countless times that the goal of these standards 
is to define "mechanism, not policy". The current instantiation of 
VWRAP, as described in the drafts, goes deep into the realm of policy 
when a web browser is involved, as it prescribes that (a) the login 
procedure results in a seed capability sent to the client, which then 
invokes it to get more capabilities; and (b) assets are pulled by 
clients. Were these fundamental for interoperability of VWs on the Web, 
then we wouldn't have an option but to accept them. But they aren't. 
They are policies -- possible implementation options.

I understand that for a client with a fixed viewer the situation is 
different: the viewer component doesn't change, so, for a fixed family 
of virtual worlds, we need to devise one single mechanism governing the 
client, the server, and the access to resources. But the Web is exactly 
this: hypermedia that includes programs.

Hence my original review comment: you need to come clear with the 
specification of the client.

It's ok to say that VWRAP is thought for clients with fixed viewers, and 
that clients with variable viewers -- like the web browser -- may want 
to follow these mechanisms because they are sensible, but they don't 
have to.

It's not ok to mislead readers of these documents into thinking that VW 
interoperability on the Web MUST follow the mechanisms prescribed here 
(as they are now).

---

From: David W Levine <[email-masked]>
Date: Fri, 24 Sep 2010 14:26:18 -0400

[email-masked] wrote on 09/24/2010 11:12:53 AM:

> Meadhbh Hamrick <[email-masked]>
>
> Cc:
>
> [email-masked]
>
> Date:
>
> 09/24/2010 11:13 AM
>
> Subject:
>
> Re: [vwrap] one question
>
> Sent by:
>
> [email-masked]
>

I don't think my answer was even slightly ambiguous. I'll quote it:

"A web based client is just another client. If it is rich enough to accept
the content and render it effectively, its a client. I don't think anyone
would say otherwise"

But if that wasn't clear enough. Yes,  the intent is to cover VWs which use
web browsers as clients.
We will ignore that "Web browsers" is itself deeply ambiguous and imprecise
and assume
reasonably capable web browsers.

> They are policies -- possible implementation options.

I think you are confusing the meanings of the words Policy and Mechanism.

The way those two phrases have been used in VWRAP is that A mechanism is
how
you do something. A policy is deciding when to use various mechanisms.

> to follow these mechanisms because they are sensible, but they don't

The capability and seed cap approach is a mechanism for securing access
to distributed resources in the internet based on REST with an interesting
mix of security, delegation and indirection features. The intent is to be
relatively client independent. There has been a rich discussion about
how to include caps to different transports, as well as how to grant caps
in interesting ways. I can imagine a good discussion on how to deal
with clients which have native websocket support.
> interoperability on the Web MUST follow the mechanisms prescribed here
This is a strawman in classic form. VWRAP proposes to solve a set of real
and useful interopability problems. Nobody has stated that it solves all
VW interoperability issues, and that ANYONE has to use it for any purpose
at all.

- David
~ Zha

---

From: David W Levine <[email-masked]>
Date: Fri, 24 Sep 2010 15:01:12 -0400

We seem to be off in the weeds a bit. Therefore I offer this:

 I believe our goal here is shared, and that we all are engaged in solving
it with good will and constructive intent. I really want to see people
asking questions and looking for answers with specific use cases, and
concrete concerns. If there is a use case that you believe is not: handled
in the current (preliminary) specifications, please offer up the use case,
and let us try to understand the use case, and the ways it might be solved,

VWRAP has a set of drafts which we all know are incomplete and in need of
revision and additional work. Concrete use cases can help us actually see
where things do or don't work for a specific situation. I would love to
discuss whether we need to extend some things to account for, example,
websocket connected clients. Constructive engagement based on concrete use
cases and respect for everyone's contributions to the process strikes me as
the way forward.

- David
~ Zha

---

From: Crista Lopes <[email-masked]>
Date: Fri, 24 Sep 2010 12:07:30 -0700

> VW interoperability issues, and that ANYONE has to use it for any purpose
I understand. The issue here is one of usefulness, and you are right 
that you probably don't want to comment on that in the drafts :). If I 
have a client with a fixed viewer, then VWRAP might be useful as a 
standard. If I have a client with hypermedia, then VWRAP doesn't seem 
that useful as a standard. I think this has been a major confusion point 
with people whose use cases are the Web. For the Web, VWRAP looks like a 
set of prescriptions that have absolutely nothing to do with 
interoperability of virtual worlds, because I expect the internal 
engineering decisions of my virtual world to be off limits from anyone 
else. So things like the login procedure or sending the assets to the 
client are my decisions only, and no one else's business. It's very 
confusing that interoperability touches on those.

Hence the other question of whether VWRAP was even about 
interoperability or not. I actually liked Meadhbh's answer that it 
wasn't -- I thought that was very consistent with the draft.

I understand VWRAP now. It's not that useful for my use case (the Web 
and everything that already exists in it) but I have nothing else to say 
about it.

---

From: Mike Dickson <[email-masked]>
Date: Fri, 24 Sep 2010 15:26:32 -0400

On 09/24/2010 03:07 PM, Crista Lopes wrote:
> with people whose use cases are the Web.
I really don't know what that means and it seems to be at the crux of 
your argument.  As David has suggested could you possibly offer up a 
concrete use case or example that you feel isn't covered by the existing 
work and we can use that as a point for discussion.
> For the Web, VWRAP looks like a
Again, I dont understand your assertion.  I need an example of the 
alternative.  SecondLife, OpenSim, etc... all use the kind of 
interaction proposed for VWRAP.  It's based on existing practice.  There 
may be better ways to do it but without a specific example its hard to 
discuss that.  You, yourself have advocated standards based on working 
code and in the VWRAP case we have that.  You need to provide examples 
of what doesn't work or we can't have a meaningful discussion.

Mike

---

From: "Hurliman, John" <[email-masked]>
Date: Fri, 24 Sep 2010 13:38:08 -0600

> Of Crista Lopes
> Sent: Friday, September 24, 2010 12:08 PM
> To: David W Levine
> Cc: [email-masked]; [email-masked]
> > This is a strawman in classic form. VWRAP proposes to solve a set of
> > real and useful interopability problems. Nobody has stated that it
> > solves all VW interoperability issues, and that ANYONE has to use it
> > for any purpose at all.
> >
> I understand. The issue here is one of usefulness, and you are right that you
> probably don't want to comment on that in the drafts :). If I have a client with
> a fixed viewer, then VWRAP might be useful as a standard. If I have a client
> with hypermedia, then VWRAP doesn't seem that useful as a standard. I
> think this has been a major confusion point with people whose use cases are
> the Web. For the Web, VWRAP looks like a set of prescriptions that have
> absolutely nothing to do with interoperability of virtual worlds, because I
> expect the internal engineering decisions of my virtual world to be off limits
> from anyone else. So things like the login procedure or sending the assets to
> the client are my decisions only, and no one else's business. It's very
> interoperability or not. I actually liked Meadhbh's answer that it wasn't -- I
> thought that was very consistent with the draft.
> 
> I understand VWRAP now. It's not that useful for my use case (the Web and
> everything that already exists in it) but I have nothing else to say about it.
> 

How far can we take this line of reasoning?

OpenID is not useful for the web because it makes all these assertions about having to serve up carefully crafted HTTP endpoints with very specific content. This forces specific design decisions when I could just package up the authentication mechanism into a Javascript application that knows how to authenticate with its home server.

WebSockets is not a useful web standard because it forces me to use a specific HTTP request/response followed by a text stream over a TCP pipe. This should be an internal engineering decision! My Javascript application knows how to talk with its home server already.

Why is WebFinger trying to get into the gritty details of how to make an identity request and what to respond with? Why not just say "grab this Javascript blob and execute it and it will fetch all of the information it needs"?

Have we suddenly removed the need for all web standards other than a method of fetching Javascript blobs and executing them?

John

---

From: Crista Lopes <[email-masked]>
Date: Fri, 24 Sep 2010 13:01:37 -0700

On 9/24/2010 12:38 PM, Hurliman, John wrote:
> Have we suddenly removed the need for all web standards other than a 
> method of fetching Javascript blobs and executing them?

Of course not.
It just seems very odd that web-based virtual worlds that want to 
interoperate need to follow some standard for sending the assets to the 
clients. This just doesn't seem related to interoperability between 
independently-operated virtual worlds. They way I do it and the way you 
do it doesn't seem related to our ability to send our users to each 
other's world.

---

From: Morgaine <[email-masked]>
Date: Fri, 24 Sep 2010 21:03:37 +0100

Crista, I believe you've misunderstood David's post here.

He simply pointed out that your logic was flawed as you had used a straw man
argument, and from such an argument one can derive no logical conclusion at
all.

That's fair.  We need to point out such mis-steps in the conversation,
otherwise this turns into a handwaving debate, whereas what we're after is a
well-formed technical discussion.

And David's point was accurate.  You had made a claim about VWRAP
interoperability that bore no relationship to anything published nor said,
and then you argued against it.  That was wrong.  And now, as a result, it's
led to even more erroneous conclusions.  Such flawed lines of reasoning
don't lead anywhere useful.

After just a few days here, it's no surprise that some parts of the protocol
and the intent are still puzzling to you, but that is addressed by letting
us explain them, not by inventing incorrect interpretations after such short
exposure.

We're all very interested in making VWRAP easily understandable to anyone
with an interest, and we fully accept that the current draft documents do
not approach that intended goal at all.  But all this can be fixed, and I
don't see any disparity of goals at all.

Morgaine.

=======================

On Fri, Sep 24, 2010 at 8:07 PM, Crista Lopes <[email-masked]> wrote:

>>  I understand. The issue here is one of usefulness, and you are right that
> you probably don't want to comment on that in the drafts :). If I have a
> client with a fixed viewer, then VWRAP might be useful as a standard. If I
> have a client with hypermedia, then VWRAP doesn't seem that useful as a
> standard. I think this has been a major confusion point with people whose
> use cases are the Web. For the Web, VWRAP looks like a set of prescriptions
> that have absolutely nothing to do with interoperability of virtual worlds,
> because I expect the internal engineering decisions of my virtual world to
> be off limits from anyone else. So things like the login procedure or
> sending the assets to the client are my decisions only, and no one else's
> business. It's very confusing that interoperability touches on those.
>
> Hence the other question of whether VWRAP was even about interoperability
> or not. I actually liked Meadhbh's answer that it wasn't -- I thought that
> was very consistent with the draft.
>

---

From: Crista Lopes <[email-masked]>
Date: Fri, 24 Sep 2010 13:13:46 -0700

On 9/24/2010 1:03 PM, Morgaine wrote:
> interoperability that bore no relationship to anything published nor 
> said, and then you argued against it.  That was wrong.  And now, as a 
> result, it's led to even more erroneous conclusions.  Such flawed 
> lines of reasoning don't lead anywhere useful.

Sorry, I lost track of which part you are referring to.

Answering Mike Dickson:

OpenSimulator is not tied to the SL viewer. The viewer protocols are 
plugins. There's at least a couple of people developing for Unity3D 
front-ends. We've been supporting the SL viewer so that we didn't need 
to develop both the server and the client at the same time. But as the 
Web gets more 3D-friendly, there is no question in a lot of people's 
minds (including mine) that a browser-based viewer is what we want -- at 
least that's what I want.
My concrete use case is my student's JavaScript+HTLM5 viewer for 
OpenSim, where VWRAP seems like a set of prescriptions that, as sensible 
as they may be, have nothing to do with interoperability.

But let's follow David's advice. On my part, I understand everything 
that I didn't understand before. I hope the discussions about the web 
browser have been useful for the people working on VWRAP too.

---

From: Morgaine <[email-masked]>
Date: Fri, 24 Sep 2010 21:14:04 +0100

On Fri, Sep 24, 2010 at 9:01 PM, Crista Lopes <[email-masked]> wrote:

> It just seems very odd that *web-based virtual worlds* that want to
> independently-operated virtual worlds. They way I do it and the way you do
> it doesn't seem related to our ability to send our users to each other's
> world.
>
>
Crista, to help this discussion become more technical, could you please
define "*web-based virtual worlds*" for us, in sufficient technical detail
to allow us to distinguish them from the much better known types of virtual
world such as those we build from OpenSimulator?

Morgaine.

============================

On Fri, Sep 24, 2010 at 9:01 PM, Crista Lopes <[email-masked]> wrote:

> independently-operated virtual worlds. They way I do it and the way you do
> it doesn't seem related to our ability to send our users to each other's
> world.
>
>

---

From: Crista Lopes <[email-masked]>
Date: Fri, 24 Sep 2010 13:16:59 -0700

On 9/24/2010 1:14 PM, Morgaine wrote:
> On Fri, Sep 24, 2010 at 9:01 PM, Crista Lopes <[email-masked] 
>         Have we suddenly removed the need for all web standards other
>         than a method of fetching Javascript blobs and executing them?
>
>
>     Of course not.
>     It just seems very odd that *web-based virtual worlds* that want
>     to interoperate need to follow some standard for sending the
>     assets to the clients. This just doesn't seem related to
>     interoperability between independently-operated virtual worlds.
>     They way I do it and the way you do it doesn't seem related to our
>     ability to send our users to each other's world.
>
>
> Crista, to help this discussion become more technical, could you 
> please define "*web-based virtual worlds*" for us, in sufficient 
> technical detail to allow us to distinguish them from the much better 
> known types of virtual world such as those we build from OpenSimulator?

I already did, but here it goes one more time: virtual worlds that use 
the web browser as the client component.

---

From: Morgaine <[email-masked]>
Date: Fri, 24 Sep 2010 21:20:33 +0100

That does not define any kind of virtual world.  It defines a client type.

Please define the *WORLD* type, not by reference to something outside the
world.

Morgaine.

On Fri, Sep 24, 2010 at 9:16 PM, Crista Lopes <[email-masked]> wrote:

> I already did, but here it goes one more time: virtual worlds that use the
> web browser as the client component.
>
>
>

---

From: "Hurliman, John" <[email-masked]>
Date: Fri, 24 Sep 2010 14:32:25 -0600

> Sent: Friday, September 24, 2010 1:02 PM
> To: [email-masked]
> it doesn't seem related to our ability to send our users to each other's world.
> 

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?

John

---

From: Crista Lopes <[email-masked]>
Date: Fri, 24 Sep 2010 13:39:42 -0700

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.

---

From: "Hurliman, John" <[email-masked]>
Date: Fri, 24 Sep 2010 14:46:10 -0600

> Sent: Friday, September 24, 2010 1:40 PM
> To: [email-masked]
> 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.

John

---

From: Crista Lopes <[email-masked]>
Date: Fri, 24 Sep 2010 14:03:23 -0700

> 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…
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?

---

From: Crista Lopes <[email-masked]>
Date: Fri, 24 Sep 2010 14:04:17 -0700

On 9/24/2010 1:20 PM, Morgaine wrote:
> Please define the *WORLD* type, not by reference to something outside 
> the world.
>

It's a web application that sends 3D graphics to the web browser.

---

From: Morgaine <[email-masked]>
Date: Fri, 24 Sep 2010 22:05:36 +0100

On Fri, Sep 24, 2010 at 9:39 PM, Crista Lopes <[email-masked]> wrote:

>  The disconnect is on things that are written on the drafts.

The drafts are decidedly odd, and in large part, quite unrelated to our
goals.  Yes, we accept that, and we have not tried to defend their rather
obvious failings.  They're a legacy of days past, and under some
interpretations are even "anti-interop".  But that is not the goal of the
working group.  They can be fixed, and they WILL be fixed if we can muster
sufficient cooperative spirit.

But talking about cooperative spirit, it is also important that we avoid
conjuring up differences where none exist.  We also need to partition the
problem space into its component parts, and define standard protocols so
that servers and clients can be developed separately --- this is essential
to allow them to improve and evolve independently.  Virtual worlds are far
more complex than web pages, and can't be handled in the same ad hoc fashion
as web pages if we expect any useful amount of interop to occur.

Morgaine.

On Fri, Sep 24, 2010 at 9:39 PM, Crista Lopes <[email-masked]> 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.
>
>

---

From: "Hurliman, John" <[email-masked]>
Date: Fri, 24 Sep 2010 15:23:19 -0600

Comments inline.

> Sent: Friday, September 24, 2010 2:03 PM
> To: [email-masked]
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Crista Lopes
> >>> interoperate with other clients that are written by other people
> >>> (and may not be written in Javascript at all) you need to expose
> > 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.
> >
> >
> 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.
> 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

---

From: Sean Hennessee <[email-masked]>
Date: Fri, 24 Sep 2010 14:28:06 -0700

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:
>>> agree with
>> 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.
>>
> make a bunch of decisions about how the browser gets the assets. These
> decisions are noone's business. I think we agree.
>

-- 

Sean Hennessee
UC Irvine

---

From: Sean Hennessee <[email-masked]>
Date: Fri, 24 Sep 2010 14:33:13 -0700

And in some cases I have to open an external stand-alone application to 
view the video from *some other* site because they don't have a plug-in.

(I didn't want to leave out the stand-alone application, since that is 
what most if not all of the *current* applications are for Opensim/SL.)

Peace,
Sean

-- 

Sean Hennessee
UC Irvine

---

From: Crista Lopes <[email-masked]>
Date: Fri, 24 Sep 2010 14:42:47 -0700

On 9/24/2010 2:23 PM, Hurliman, John wrote:
>
> 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.
I was not thinking about the JavaScript program accessing the other 
world's assets directly, but there you go: you thought about it, so you 
might do it, while I might not.

> 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*.
I'm not. The interop should be world-to-world. The JavaScript program is 
just a renderer and UI.

> 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.
>
>    

ok. It's good to know that this is out of scope!

> 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…
Well, *some* interop protocol, I agree. I'm not convinced that VWRAP, as 
described in the documents, is needed.

> 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 w…

Great. Now can you please explain to me why this matters for interop:
http://tools.ietf.org/html/draft-ietf-vwrap-authentication-00
Not just the title, but the actual content of that draft.

---

From: Morgaine <[email-masked]>
Date: Fri, 24 Sep 2010 23:03:36 +0100

If I'm reading this correctly, there is no difference at all between
"web-based virtual worlds" and the kind we already know.  All that is being
stated repeatedly is that the world has a Web interface.  Well that is not
an actual difference in the world, just an extra interface or feature.

It looks to me like we have no distinct *VIRTUAL WORLD* use case here at
all.

+1 to John when he wrote:

On Fri, Sep 24, 2010 at 9:32 PM, Hurliman, John <[email-masked]>wrote:

> precise specs.

Indeed.  I think it's going to be very common that worlds have their own
distinctive interfaces and other features.  But it is extremely likely that
most worlds will be based on standard world frameworks like OpenSimulator
behind those interfaces, because developing worlds is hard, and reusing
existing software is much easier and cheaper.

It appears that we have a non-issue here since there is no different world
type to consider.

Morgaine.

---

From: Crista Lopes <[email-masked]>
Date: Fri, 24 Sep 2010 16:37:05 -0700

On 9/24/2010 2:05 PM, Morgaine wrote:
> Virtual worlds are far more complex than web pages, and can't be 
> handled in the same ad hoc fashion as web pages if we expect any 
> useful amount of interop to occur.

Morgaine, just in case you missed this:
http://googlewebtoolkit.blogspot.com/2010/04/look-ma-no-plugin.html

---

From: Morgaine <[email-masked]>
Date: Sat, 25 Sep 2010 01:21:23 +0100

Sure, I've seen that Quake II demo in a browser.  Nice, and very promising.

That doesn't help us here though.

As I wrote, virtual worlds are far more complex than web pages, and can't be
handled in the same ad hoc fashion as web pages if we expect any useful
amount of interop to occur.  Browsers becoming more powerful doesn't modify
this situation at all.  Complexity doesn't decrease just because you can
process code faster with newer technology.

Morgaine.

=================================

On Sat, Sep 25, 2010 at 12:37 AM, Crista Lopes <[email-masked]> wrote:

>> Virtual worlds are far more complex than web pages, and can't be handled
>> in the same ad hoc fashion as web pages if we expect any useful amount of
>> interop to occur.
>>
>

---

From: Crista Lopes <[email-masked]>
Date: Fri, 24 Sep 2010 17:27:09 -0700

No one is talking about web pages. I'm talking about web applications: 
what's behind an URL is a complex system -- like Facebook, but with a 3D 
component to it.

On 9/24/2010 5:21 PM, Morgaine wrote:
> As I wrote, virtual worlds are far more complex than web pages, and 
> can't be handled in the same ad hoc fashion as web pages if we expect 
> any useful amount of interop to occur.  Browsers becoming more 
> powerful doesn't modify this situation at all.  Complexity doesn't 
> decrease just because you can process code faster with newer technology.
>
>
> Morgaine.
>
>
>
>
> On Sat, Sep 25, 2010 at 12:37 AM, Crista Lopes <[email-masked] 
>         Virtual worlds are far more complex than web pages, and can't
>         be handled in the same ad hoc fashion as web pages if we
>         expect any useful amount of interop to occur.
>
>

---

From: Morgaine <[email-masked]>
Date: Sat, 25 Sep 2010 05:26:59 +0100

The "complex system" behind the URL is OpenSimulator --- you've explained
that your student is using that, and since you've been working on
OpenSimulator for a long time as a primary developer, that is of course what
we expected anyway.

But if it's OpenSimulator and not some other kind of unspecified Web app
world, then the many responses you have been given about your use case being
supported by VWRAP seem well founded.  What's more, since VWRAP has
specifically had OpenSimulator in mind from the start, it is hard to see
where the alleged problems lie.

I'd like to help more, but I'm thwarted by not being shown the actual
problem.

One of the best aspects of OpenSimulator is that it can support multiple
protocol stacks concurrently.  That's a great feature, and it seems
tailor-made for introducing a VWRAP protocol module at that interface,
perhaps configured for a minimal deployment pattern offering only teleport
and remote asset services accessible via region proxy.  Web-browser based
residents of your world could then TP to another VWRAP-enabled world, buy
some junk, and bring it back with them.  A win!

I see no showstoppers just because your native client is a Web browser.  It
would work for travellers in the other direction too.  The reason why all
this can be expected to work is that OpenSimulator runs a data model that is
compatible with the data model used by VWRAP asset services.  This is why we
say that we can't see an *a priori* problem.

If I may suggest a way out, perhaps we could continue with examining other
parts of the puzzle, and when something arises that might not work with
those "web-based virtual worlds" you could raise a red flag for us?  Asset
services need to be an early item of discussion anyway, so we ought to see
quite soon if something is askew in the model.

Morgaine.

======================================

On Sat, Sep 25, 2010 at 1:27 AM, Crista Lopes <[email-masked]> wrote:

> As I wrote, virtual worlds are far more complex than web pages, and can't
> be handled in the same ad hoc fashion as web pages if we expect any useful