Subject: [vwrap] Consensus? What exactly should be in the protocol

From: Meadhbh Hamrick <[email-masked]>
Date: Tue, 21 Sep 2010 11:15:56 -0700

hey peeps...

so after yesterday's fireworks, i think it's safe to say the group
agrees we're trying to build standards for "some kind of virtual
experience." we agree that the group should define "services," to
simulate the virtual world. and we should define enough services that
a software developer could take our documents and code something that
has a good chance of a) interoperating with other software developer's
output and b) provides a reasonably complete virtual world experience.
further, i _think_ we agreed there should be no requirement that a
service deployer should have to deploy ALL the services we define;
it's up to the individual deployer what services they want to offer.

a lot of people on this list have experience with Linden's Second Life
Viewer (and similar programs.) i think the experience of a virtual
world through this program has shaped a lot of people's recent
opinions of what should and what shouldn't be in a virtual world.

josh bell gave a presentation titled "what's *not* in VWRAP" at last
spring's IETF face to face in anaheim. you can find the notes here:
http://www.ietf.org/proceedings/10mar/slides/vwrap-6.pdf [warning,
PDF.]

to begin the discussion, i'm going to list a few things i think should
be standardized by this group, then a few things that i think
shouldn't. please note that i'm all for standardization, it's just
that for some of these features we may want to rely on what josh
refers to as "convention" rather than standardization. in other words,
peeps should definitely develop standards for enough stuff to be able
to render a virtual world with terrain, objects and avatars, but i
don't think this group has to standardize everything (like postcards.
why the heck do postcards go through linden's servers when it's
EXTREMELY likely that if you have a second life account you also have
an email account. but i digress.)

so here's my list. i'm not trying to tell people the is the only list
that would ever work. they're just my thoughts...

* type system - in

i'm a big fan of the abstract type system and it's related
serialization schemes. i'm not the world's biggest fan of LLIDL. i
like what it's trying to do, but all that line noise used to define
resources is annoying.

* authentication - in or out? BOTH

so now that linden has de-emphasized their participation in this
group, and we probably won't know for a while if they'll ever
implement anything we specify, why bother with legacy linden
authentication. their current "legacy" auth goes over XML-RPC which
IMHO is the internet equivalent of a skin disease that you just can't
get to go away. it also uses MD5. i can't express my feelings for MD5
in polite company.

there are some very interesting conversations / arguments going on
regarding OAuth. it's a well understood authorization technology that
many of us on the list have used in the past. OpenID is also vaguely
popular, though i'm not it's biggest fan. i do know that some of the
.edu peeps are supporting shibboleth which is (correct me if i'm
wrong) layered on top of SAML.

however... there is one aspect of the current auth spec that is (IMHO)
"really cool." and that's the part that provisions a seed capability.
zha and i have bounced up and down about how caps solve some vexing
problems dealing with loosely coupled collections of services.

also, most current OAuth instances like to direct people to HTML web
pages. this can be a problem for peeps with desktop  apps. yes, you
can integrate a web browser with your viewer and capture the final
redirect. btw, one of linden's problems with this idea was you got
software distributed by linden that redirects people to web pages
owned by other people, and this sorta freaks some corporate users out.

so... were i the empress of all the internet, i would decree that
linden legacy auth and linden OGP auth be deprecated and declare that
implementers were free to use whatever auth technology they want to
use to authenticate the user prior to giving them their seed cap. but
because i was a kind monarch, i would define one or two standard,
thought non-normative, techniques for using other auth technologies.

so instead of calling this auth, i would go back to calling it
"service establishment."

* maintenance - IN

if you look at the existing auth spec, there's a resource defined for
login-time user maintenance. it's pretty straight forward to support
on the client side, and there's no requirement that you have to use it
on the server side.

* account properties - some IN, mostly OUT

i think we should have a standard way for a client or service to
request basic information about a user, an agent or an avatar. but
honestly, i think a lot of the stuff that get's displayed in the
Second Life Viewer's profile floater could just as easily be rendered
as a web page.

* agent / avatar control - IN

yes, we should define a standard set of messages for controlling the
user's avatar. however, i think we should build an extensible control
sub-protocol. so maybe we start with messages labeled 'CONTROL-MOVETO'
to define how the user's
avatar should be moving around the virtual world. later we may want to
add 'CONTROL-ANIMATION' for synchronizing an avatar's animation with
real-life events from the client.

* asset access - IN

there's lotsa fun stuff that's been hypothesized for next generation
assets. suffice to say, at the very least manipulation of meta-data
and a way get link objects in user's inventories and objects in world
with objects in an asset server is "a good thing."

* asset upload - OUT? maybe? IN? kinda

there are plenty of great protocols and data formats for defining
assets. X3D, COLLADA, etc. and HTTP PUT is well understood. so i don't
know that we have to create any new protocols for uploading assets.
but we may want to define a technique by which a user can tell an
asset server it's wants to upload something and then the asset server
gives the client a URL to a HTTP PUT resource where it can upload it.

* build tools - OUT

the ability to do "group builds" in second life and OpenSim instances
is one of the compelling things about those worlds. i think there
should be a standardized way to do builds "in world." but IMHO, SL
does it wrong. OpenSim inherited SL's wrongness. we could do it MUCH
better. but i would recommend we pass on building a standard for it in
this group.

* communication - some IN, some OUT

anyone who's experienced the "joy" of second life's group chat feature
can quickly see how it's not up to the task. XMPP is a PERFECTLY GOOD
chat protocol. however, for spatial chat, you would probably want some
way to identify a location in the virtual world as the endpoint of a
chat message, so at the very least we should have enough specification
for how to represent locations or avatars in the virtual world for
XMPP or SIMPLE or IRC or whatever chat protocol we would want to use.

but the existing linden legacy protocol chat should definitely be
deprecated. or caught in a dark alleyway when no one's around and put
out of it's misery.

* event profiles - OUT

this is something that should be a web page

* friends and groups - OUT? IN?

this is a tough one. groups are kind of an important part of second
life's social fabric. but i have a hard time justifying a group access
and management protocol when i know that the first thing a third party
is going to do is ignore the protocol and implement something that
talks to twitter or facebook.

but... it is still nice to have some standard way to query a user's
presence. maybe the thing to do is to define a
"presence field" in a user or avatar's public profile. you could then
stuff the URL to your public profile on your facebook page or some
twitter app somewhere and virtual world clients could "do the right
thing" by querying your social network on facebook / twitter / avatars
united / etc, reaping the links to user's public profiles and then
querying their presence status.

or maybe i should just shut up and go code some examples.

anyway... thoughts?

* parcels - OUT! OUT! A THOUSAND TIMES OUT!

parcels are a linden invention that (IMHO) should not be part of this
protocol standard. i'm all for lindens making publicly defined
extensions to describe their parcel system, but i don't think every
region should be forced to carry this bit of linden baggage.

* land and region profile - IN

on the other hand, it's good to know a thing or two about the virtual
land upon which your avatar stands (like where to go to get the scene
graph). that should definitely be in the protocol.

* search - OUT

this should be a web page.

* teleport - IN

* virtual currency - OUT

* world map - OUT

* "space server" - IN

this is the resource that defines the adjacency and shape of various
regions. i don't think we could have a meaningful virtual world
experience without it.

okay... these are just some ideas to kick-start the conversation. i'm
interested to hear what other peeps think. if i didn't mention your
favorite service it was an oversight, not a slight.

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

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 21 Sep 2010 14:09:20 -0700

Where does process migration fit in?

That could include simple script migration from server to client or from 
server to server. It could include migration from system to subsystem.

Meadhbh Hamrick wrote:
> _______________________________________________
> vwrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vwrap
>
>   

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

---

From: Cristina Videira Lopes <[email-masked]>
Date: Tue, 21 Sep 2010 17:47:10 -0700

On Sep 21, 2010, at 11:15 AM, Meadhbh Hamrick wrote:

> experience."

I think this can be nailed down a lot better, Meadhbh. Or maybe there  
are completely different goals at play here. Probably the latter,  
let's see.

Here's what I think would be really cool for this group to do: this  
group could be trying to build standards for portable user agent  
simulation state, a part of which, but not all, is portable identity.  
Where:

1) "portable" means what it means on the Web: communicated between  
sites in different trust domains
2) "user agent" means what it already means on the web: the data that  
represents the user on the web server
3) "simulation" is the new thing that these web apps do: they take the  
user agent data and place it in a  simulation of a 3D environment,  
possibly, but not necessarily, giving the user a visual representation  
called 'avatar'. As the simulation proceeds, the user agent data may  
change.

I think it's very uninteresting -- and mostly void of any effect in  
practice -- that this group engages in the design of a standardized  
virtual world user experience, e.g. making the SL features be a  
standard for all virtual worlds. For example, they all have maps! they  
all have IM! they all have currency! etc. -- that's as pointless as  
trying to standardize the user experience for social network  
applications.

> we agree that the group should define "services," to
> simulate the virtual world.
> and we should define enough services that

---

From: "Hurliman, John" <[email-masked]>
Date: Tue, 21 Sep 2010 22:14:47 -0600

This is closer to what I had in my head for VWRAP. Start with the goal of a portable virtual world presence, and a couple of necessary services fall out of that:

* Identity/Authentication
* Assets (possibly Inventory, maybe)
* Teleport (both login and simulation to simulation)

Which will in turn require:

* Type system
* Capabilities/X.509/insert_security_here
* Avatar file format?
* Event queue?

And leave everything else for VWRAP2. If we can standardize those services and meet that first goal it will be much easier to tackle things like friends or groups or avatar movement / state simulation or anything else. I don't know if there is any industry demand for a virtual world avatar movement RFC, but other people have different perspectives. I'm strongly in favor of working toward the portable virtual world presence and supporting service definitions first though.

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Cristina Videira Lopes
> Sent: Tuesday, September 21, 2010 5:47 PM
> To: Meadhbh Hamrick
> Cc: [email-masked]
> Subject: Re: [vwrap] Consensus? What exactly should be in the protocol
>

---

From: Mike Dickson <[email-masked]>
Date: Wed, 22 Sep 2010 09:39:23 -0400

> And leave everything else for VWRAP2. If we can standardize those services and meet that first goal it will be much easier to tackle things like friends or groups or avatar movement / state simulat…
I like this list for a first effort though it leaves alot unspecified 
and from a user perspective a system that just implements to this level 
won't be terribly exciting.  That doesn't mean that implementations 
can't fill in extras (things like IM, currency, script compatability, 
etc may be uninteresting to some but if your trying to implement a 
production system they become important to the user experience pretty 
quickly).

I think if we focus on John's list, identify how services decompose that 
implement that and then specify that as VWRAP we'd have made a good 
initial effort and can then move on to some of the more difficult issues.

Mike

---

From: Morgaine <[email-masked]>
Date: Wed, 22 Sep 2010 15:34:31 +0100

The general idea in VWRAP was to neither prescribe nor proscribe any
particular set of services, but it's certainly important to enumerate, and
to define the hooks to handle, all the common service options, otherwise as
Mike says, worlds are not going to be very interesting.

Anything that we do today in SL and in Opensim-type worlds deserves to be on
the list, and different developers will no doubt implement different sets of
them in accordance with their needs and interests.  All the ones mentioned
here are reasonable, but we need to add several more.

Being listed means merely that *someone* can implement it if they want to as
a demo VWRAP service, not that it's mandatory.  Even stub implementations
are helpful, and will help us to test out concepts.

Morgaine.

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

On Wed, Sep 22, 2010 at 2:39 PM, Mike Dickson <[email-masked]> wrote:

>> This is closer to what I had in my head for VWRAP. Start with the goal of
>> a portable virtual world presence, and a couple of necessary services fall
>> out of that:
>>
>> And leave everything else for VWRAP2. If we can standardize those services
>> and meet that first goal it will be much easier to tackle things like
>> friends or groups or avatar movement / state simulation or anything else. I
>> don't know if there is any industry demand for a virtual world avatar
>> movement RFC, but other people have different perspectives. I'm strongly in
>> favor of working toward the portable virtual world presence and supporting
>> service definitions first though.
>>
>> John
>>
> I like this list for a first effort though it leaves alot unspecified and
> from a user perspective a system that just implements to this level won't be
> terribly exciting.  That doesn't mean that implementations can't fill in
> extras (things like IM, currency, script compatability, etc may be
> uninteresting to some but if your trying to implement a production system
> they become important to the user experience pretty quickly).
>
> implement that and then specify that as VWRAP we'd have made a good initial
> effort and can then move on to some of the more difficult issues.
>
> Mike
>
>

---

From: Meadhbh Hamrick <[email-masked]>
Date: Wed, 22 Sep 2010 07:38:47 -0700

kk. i _think_ i'm sensing a pattern... people interested in a more
expansive view of this effort seem to be interested in client
behavior.

some of us over on the "let's just do a protocol" side of the debate
are fine to give only a small bit of guidance under the guise of
"processing expectations."

is this a fair statement?

the obvious next place i'm going with this is to see if we can break
the "client behavior" piece off and have it run by a different group
(sort of like the IETF/W3C split with HTML5/HTTPbis.) the IETF has
typically been a community focused on wire protocols. i don't want to
diminish anyone's actual or potential contributions here, but it seems
that Diva and Morgaine are interested in a much more expansive problem
domain. i'm worried that this group and this organization is not
equipped to properly address some of those issues.

(and this is going to sound like i'm totally dissing Diva and
Morgaine, but i'm actually not, just hear me out.) i'm just thinking
that it might reduce friction if those of us interested in wire
protocol worked on a wire protocol, while those people interested in
specifying a product / project, etc. take those more expansive
conversations to a forum more appropriate for their discussion.

but the fact that people with a "more expansive" interest have landed
here makes me wonder... what IS the forum for these more expansive
discussions? i fear it doesn't really exist, and that's why we have
such wide ranging discussions here.

i have no problems with the things that Diva or Morgaine have posted,
but at the end of the day, i'm not interested in defining a protocol
that is SOLELY about rendering a virtual world. i would like my auth
protocol to allow facebook and twitter groups to show up in my virtual
world client. i would like a web app that (like XStreetSL) renders a
virtual object on a web page, but i want that object to be rendered
from data retrieved directly from the asset server.

my fear is that as we start talking about state diagrams for virtual
world clients and hard definitions of virtual worlds, we lose site of
what this group was originally chartered for: to specify a wire
protocol of sufficient specificity that software developers could
write code that had a fighting chance to be interoperable.

in the past i've made flip comments to morgaine of the effect... "if
you're interested in talking about interop between virtual worlds,
take the discussion to MMOX, where it belongs."

but seriously... if we're interested in something more than a wire
protocol, we may want to try to recharter.

or at the very least, could we agree to move the discussion of "what
is a virtual world" to the MMOX list? if we did that, i would promise
to NEVER say anything about how discussions are out of scope on that
list, ever.

i'm proposing that we reserve the VWRAP list for discussions of the
wire protocol while the MMOX list is more about "open ended"
discussions. on MMOX, we could have extensive conversations about a
more expansive problem domain with the view that consensus on that
list could lead to a new charter on this one.

and in the meantime, we could focus here on a very small subset of
things like mike, john and i seem to be suggesting.

just an idea.

---

From: Meadhbh Hamrick <[email-masked]>
Date: Wed, 22 Sep 2010 07:47:21 -0700

yeah. i see your point morgaine.

but... (yes, there's always a "but")

those of us who will be implementing these specs are likely interested
in (as david calls it) "boiling the ocean one thimble at a time."

it's important to realize that if we recharter with a very small list
of features, we can then very easily recharter later to include more
of the problem domain.

maybe there's room for a couple documents... one that's like "this is
where we eventually want to get to" and that would be the one where we
all throw our eventual use cases in.

then every couple of years we carve off another set of functionality.

i believe barry can confirm that it's possible to recharter groups and
that it's WAAAY easier to add functionality to a group's charter than
to remove it.

i'm mildly concerned that we've blown waaaay past our document
deadlines, and in large part the reason seems to be we keep
antagonizing each other about scope.

On Wed, Sep 22, 2010 at 7:34 AM, Morgaine
<[email-masked]> wrote:
> Being listed means merely that someone can implement it if they want to as a
> demo VWRAP service, not that it's mandatory.  Even stub implementations are
> helpful, and will help us to test out concepts.
>
>
> Morgaine.
>
>
>
>
>
>>> And leave everything else for VWRAP2. If we can standardize those
>>> services and meet that first goal it will be much easier to tackle things
>>> like friends or groups or avatar movement / state simulation or anything
>>> else. I don't know if there is any industry demand for a virtual world
>>> avatar movement RFC, but other people have different perspectives. I'm
>>> strongly in favor of working toward the portable virtual world presence and
>>> supporting service definitions first though.
>>>
>>> John
>>

---

From: Cristina Videira Lopes <[email-masked]>
Date: Wed, 22 Sep 2010 07:51:40 -0700

Meadhbh, most of your observations are completely off. But one is not: 
the one about some of us (well, me, at least) paying attention to the 
larger context of the protocols.

The thing to have in mind is that the Web is not just a protocol. It's a 
set of design principles for large-scale decentralized systems, as I 
explained in some previous email (extended version of it in one of our 
former grad student's PhD thesis: 
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm). If we go 
and start hammering in protocols that go against those design 
principles, chances are those protocols are going to be completely 
ignored, because the design principles of the Web have proven to be 
extremely beneficial for diversity and scalability, and a lot of people 
simply aren't interested in giving up on the freedom that the Web design 
principles offer.

If interoperability of virtual worlds that use the Web design principles 
are out of scope of this group, I'll be glad to go elsewhere, because, 
as I said, that's my main interest in here.

---

From: Morgaine <[email-masked]>
Date: Wed, 22 Sep 2010 16:00:31 +0100

The whole idea in the VWRAP model is to allow new services to be added and
changed very easily.  Requiring a new group charter, a new protocol features
list, and 2-year delay for a new WG iteration just to add some new services
is most definitely not the idea behind VWRAP! :-)

I reject that suggestion and the continual rechartering for new services
completely.

Morgaine.

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

On Wed, Sep 22, 2010 at 3:47 PM, Meadhbh Hamrick <[email-masked]>wrote:

> and
> initial

---

From: Cristina Videira Lopes <[email-masked]>
Date: Wed, 22 Sep 2010 08:28:01 -0700

OK. If more people are interested in this formulation, let's go ahead 
with this.
It looks like Meadhbh, who has been the only active draft writer as far 
as I can tell (!),  doesn't like/want/? this formulation, so she is not 
in a position to write it down. It is completely unfair of us, and 
mutually frustrating, to expect that she is going to write down things 
that she doesn't like/want. So someone else needs put their money where 
their mouth is, and spend a couple of days writing an intro draft that's 
alternative to the one that is currently active, and that reflects 
everyone else's expectations on the existence of [virtual world] 
application domains of trust.

Maybe once we have an alternative intro document, we can all converge.

Any takers?

Hurliman, John wrote:
>>> has a good chance of a) interoperating with other software
>>>       
>> developer's
>>     
>>> output and b) provides a reasonably complete virtual world
>>>       
>> experience.
>>     
>>> a lot of people on this list have experience with Linden's Second
>>>       
>> Life
>>     
>>> to begin the discussion, i'm going to list a few things i think
>>>       
>> should
>>     
>>> refers to as "convention" rather than standardization. in other
>>>       
>> words,
>>     
>>> however... there is one aspect of the current auth spec that is
>>>       
>> (IMHO)
>>     
>>> owned by other people, and this sorta freaks some corporate users
>>>       
>> out.
>>     
>>> on the client side, and there's no requirement that you have to use
>>>       
>> it
>>     
>>> on the server side.
>>>
>>> sub-protocol. so maybe we start with messages labeled 'CONTROL-
>>>       
>> MOVETO'
>>     
>>> to define how the user's
>>> avatar should be moving around the virtual world. later we may want
>>>       
>> to
>>     
>>> assets. X3D, COLLADA, etc. and HTTP PUT is well understood. so i
>>>       
>> don't
>>     
>>> better. but i would recommend we pass on building a standard for it
>>>       
>> in
>>     
>>> this group.
>>>
>>> anyone who's experienced the "joy" of second life's group chat
>>>       
>> feature
>>     
>>> chat protocol. however, for spatial chat, you would probably want
>>>       
>> some
>>     
>>> chat message, so at the very least we should have enough
>>>       
>> specification
>>     
>>> life's social fabric. but i have a hard time justifying a group
>>>       
>> access
>>     
>>> and management protocol when i know that the first thing a third
>>>       
>> party
>>     
>>> thing" by querying your social network on facebook / twitter /
>>>       
>> avatars
>>

---

From: Morgaine <[email-masked]>
Date: Wed, 22 Sep 2010 16:59:52 +0100

Discussing what should be in draft protocol documents prior to actually
writing them would be a good idea.  We've suffered from this problem here
repeatedly, in that documents are just sprung on us and then it's a major
fight to get them back to a mutually acceptable common base.

It would be infinitely more useful to find the common base first.  Documents
have immense inertia, and the less in them that needs revising at a core
conceptual level, the less time is wasted by everyone.  A little planning is
a major time saver here.

Morgaine.

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

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

>  OK. If more people are interested in this formulation, let's go ahead with
> this.
> It looks like Meadhbh, who has been the only active draft writer as far as
> I can tell (!),  doesn't like/want/? this formulation, so she is not in a
> position to write it down. It is completely unfair of us, and mutually
> frustrating, to expect that she is going to write down things that she
> doesn't like/want. So someone else needs put their money where their mouth
> is, and spend a couple of days writing an intro draft that's alternative to
> the one that is currently active, and that reflects everyone else's
> expectations on the existence of [virtual world] application domains of
> trust.
>
> From: [email-masked] [mailto:[email-masked] <[email-masked]>] On Behalf
> spring's IETF face to face in anaheim. you can find the notes here:http://www.ietf.org/proceedings/10mar/slides/vwrap-6.pdf [warning,
> PDF.]
>
> vwrap mailing [email-masked]://www.ietf.org/mailman/listinfo/vwrap
>
> vwrap mailing [email-masked]://www.ietf.org/mailman/listinfo/vwrap
>
> vwrap mailing [email-masked]://www.ietf.org/mailman/listinfo/vwrap
>
>
>

---

From: Cristina Videira Lopes <[email-masked]>
Date: Wed, 22 Sep 2010 09:12:36 -0700

Fair, Morgaine.
Here's an attempt at a plan for what could be in that draft.

(1) Goal of the group: develop standards for portable user agent 
simulation state (expand on that)
(2) Granularity of portability: virtual world application (expand on that)
(3) Principles of such standards: as close to the design principles of 
the Web as possible (summarize)

For (1) we need definitions for just about every word in there, which I 
started to do, and we also need a good definition of "state" itself. 
What is that state that gets ported around?

For (2), I liked your long analysis, but I think there's a shorter way 
to get where you got, we really don't need to reinvent the Web :) But we 
can work on that.

Morgaine wrote:
> Discussing what should be in draft protocol documents prior to 
> actually writing them would be a good idea.  We've suffered from this 
> problem here repeatedly, in that documents are just sprung on us and 
> then it's a major fight to get them back to a mutually acceptable 
> common base.
>
> It would be infinitely more useful to find the common base first.  
> Documents have immense inertia, and the less in them that needs 
> revising at a core conceptual level, the less time is wasted by 
> everyone.  A little planning is a major time saver here.
>
>
> Morgaine.
>
>
>
>
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     OK. If more people are interested in this formulation, let's go
>     ahead with this.
>     It looks like Meadhbh, who has been the only active draft writer
>     as far as I can tell (!),  doesn't like/want/? this formulation,
>     so she is not in a position to write it down. It is completely
>     unfair of us, and mutually frustrating, to expect that she is
>     going to write down things that she doesn't like/want. So someone
>     else needs put their money where their mouth is, and spend a
>     couple of days writing an intro draft that's alternative to the
>     one that is currently active, and that reflects everyone else's
>     expectations on the existence of [virtual world] application
>     domains of trust.
>
>>>     From: [email-masked] <mailto:[email-masked]> [mailto:[email-masked]] On Behalf
>>>     Cc: [email-masked] <mailto:[email-masked]>
>>>>     @OhMeadhbh * http://meadhbh.org/ * [email-masked] <mailto:[email-masked]>
>>>>     [email-masked] <mailto:[email-masked]>
>>>     [email-masked] <mailto:[email-masked]>
>>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: Meadhbh Hamrick <[email-masked]>
Date: Wed, 22 Sep 2010 09:22:07 -0700

Christina,

you may be adding a bit more to my message than is really there. i
don't want you and morgaine to "go away." i want you to stay engaged
here, but this is a group that talks about wire protocols, and the
suggestion that we try to standardize a client state model may be a
bit out of scope.

the IEEE and MPEG are working on VW standards that are much more
expansive, that might be a better forum for things like client models.

i want people who are working on such things to tell us what they
need, without telling us we're doing the wire protocol piece wrong.

but...

we have a charter which specifies a "contract" with the IESG about
what we're on the hook to deliver. at some point we need to stop
increasing the scope of this group and actually deliver something.

-cheers
-meadhbh

On Wed, Sep 22, 2010 at 7:51 AM, Cristina Videira Lopes
<[email-masked]> wrote:
> Meadhbh, most of your observations are completely off. But one is not: the
> one about some of us (well, me, at least) paying attention to the larger
> context of the protocols.
>
> The thing to have in mind is that the Web is not just a protocol. It's a set
> of design principles for large-scale decentralized systems, as I explained
> in some previous email (extended version of it in one of our former grad
> student's PhD thesis:
> http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm). If we go and
> start hammering in protocols that go against those design principles,
> chances are those protocols are going to be completely ignored, because the
> design principles of the Web have proven to be extremely beneficial for
> diversity and scalability, and a lot of people simply aren't interested in
> giving up on the freedom that the Web design principles offer.
>
> If interoperability of virtual worlds that use the Web design principles are
> out of scope of this group, I'll be glad to go elsewhere, because, as I
> said, that's my main interest in here.
>
> Meadhbh Hamrick wrote:
>

---

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

Christina,

user agent simulation state is well outside this group's charter. i
support SOMEONE working on it, but if you want this group to work on
it, we would have to recharter this working group.

if you're interested in research, you may want to investigate forming
an IRTF research group. you would get most of the benefits of working
with an IETF working group, plus most of us who are on the hook to
produce software and specifications on a deadline won't freak out when
open ended discussions break out.

even better, you and other people interested in producing a user agent
simulation state model could do so in an IRTF group, then coordinate
with us about how our wire protocols will support your model. we could
write it into our charter that one of our objectives is to support
your model and we could all get on with our lives.

the term "granularity of portability" sounds great, but i'm not sure
what it means in the context of a working group that is supposed to be
working on data formats and wire protocols.

what do you mean by "the web?" how do i write some software and then
test it to see if it adheres to the design principles of the web?

-cheers
-meadhbh

On Wed, Sep 22, 2010 at 9:12 AM, Cristina Videira Lopes
<[email-masked]> wrote:
> (1) Goal of the group: develop standards for portable user agent simulation
> state (expand on that)
> (3) Principles of such standards: as close to the design principles of the
> Web as possible (summarize)
>
> started to do, and we also need a good definition of "state" itself. What is
> that state that gets ported around?
>
> For (2), I liked your long analysis, but I think there's a shorter way to
> get where you got, we really don't need to reinvent the Web :) But we can
> work on that.
>
>
> Morgaine wrote:
>
> On Wed, Sep 22, 2010 at 4:28 PM, Cristina Videira Lopes <[email-masked]>
> wrote:
>>
> ________________________________

---

From: Cristina Videira Lopes <[email-masked]>
Date: Wed, 22 Sep 2010 09:38:32 -0700

I understand, Meadhbh :)
That's why I started my participation in this group by stating that the 
goals of this group, as chartered, were not aligned with those of the 
OpenSimulator project -- just a factual observation. Had the reaction of 
the group been "that's right, and that's not important because we have 
converged on the charter statement, and we all agree with it", that'd 
would be cool, and I would only be mildly involved. Instead, the 
reaction was
"we are very frustrated with the drafts!!!!!11!! *fireworks* *insults*"

It looks like this group is a lot less homogeneous than what you are 
trying to make it look. Which is both good and bad. It's bad that people 
have let the charter be stated in ways that do not align with their 
interests ("Single presence? That's not aligned with what I argued 
for!") It's bad that so much frustration hasn't produced alternative 
drafts yet. It's good that there are people here whose interests align 
with mine.

So I'm cool either way. We can start a new WG, or we can talk about 
portable user agent simulation state in here. It's not for you to 
decide, though, it's for the group to decide :)

---

From: Morgaine <[email-masked]>
Date: Wed, 22 Sep 2010 18:13:33 +0100

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

>
> (1) Goal of the group: develop standards for portable *user agent
> simulation state* (expand on that)
>

I think we may be witnessing the bow shock from a collision of meme systems
here. :P

VWRAP has honed its terminology rather well over the years, as has the
OpenSimulator project I'm sure, but the two sets of terminology seem to be
different.  We need to bridge this gap fast. :-)

What is "*user agent simulation state*"?

In VWRAP we have:

   - *users* (humans driving a "*client application*");
   - *agents* (the server-side embodiment of a connection from a client
   application);
   - *regions* that are primarily spatial but may orchestrate many services;
   - *simulations* that were traditionally run within a region but which in
   VWRAP may be performed by a discrete "*simulation service*" that could be
   external;
   - *world state* which is primarily held and manipulated by a *region
   service*.

(Note that the above may sound a bit like SL, but it's not really. VWRAP
services can be arranged in numerous different *deployment patterns*, and an
SL-like configuration is merely one possible deployment out of many.)

To the above should be added that we employ a *REST*-type protocol for all
upstream communication between client application and server-side services,
and being REST, clients and servers both have application state which is
accessed and modified through CRUD operations, but the protocol is stateless
as usual to provide us with the normal benefits of REST, such as
addressibility, cacheability, etc.

What we don't have is simulation state in the client application, so the
phrase you used is a bit hard to tie down using our form of language.
Explanation needed please --- I'll try to help you fit it into our
terminology if I can. :-)

Morgaine.

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

> Documents have immense inertia, and the less in them that needs revising at
> a core conceptual level, the less time is wasted by everyone.  A little
> planning is a major time saver here.
>
>
> Morgaine.
>
>
>
>
> On Wed, Sep 22, 2010 at 4:28 PM, Cristina Videira Lopes <[email-masked]
> > wrote:
>
> ------------------------------
>

---

From: Cristina Videira Lopes <[email-masked]>
Date: Wed, 22 Sep 2010 10:22:34 -0700

Definitions here:
http://www.ietf.org/mail-archive/web/vwrap/current/msg00317.html

Morgaine wrote:
> I think we may be witnessing the bow shock from a collision of meme 
> systems here. :P
>
> OpenSimulator project I'm sure, but the two sets of terminology seem 
> to be different.  We need to bridge this gap fast. :-)
>
>     * *users* (humans driving a "*client application*");
>     * *agents* (the server-side embodiment of a connection from a
>       client application);
>     * *regions* that are primarily spatial but may orchestrate many
>       services;
>     * *simulations* that were traditionally run within a region but
>       which in VWRAP may be performed by a discrete "*simulation
>       service*" that could be external;
>     * *world state* which is primarily held and manipulated by a
>       *region service*.
>
>
> (Note that the above may sound a bit like SL, but it's not really. 
> VWRAP services can be arranged in numerous different *deployment 
> patterns*, and an SL-like configuration is merely one possible 
> deployment out of many.)
>
> To the above should be added that we employ a *REST*-type protocol for 
> all upstream communication between client application and server-side 
> services, and being REST, clients and servers both have application 
> state which is accessed and modified through CRUD operations, but the 
> protocol is stateless as usual to provide us with the normal benefits 
> of REST, such as addressibility, cacheability, etc.
>
> What we don't have is simulation state in the client application, so 
> the phrase you used is a bit hard to tie down using our form of 
> language.  Explanation needed please --- I'll try to help you fit it 
> into our terminology if I can. :-)
>
>
> Morgaine.
>
>
>
>
>
>     (3) Principles of such standards: as close to the design
>     principles of the Web as possible (summarize)
>
>     For (1) we need definitions for just about every word in there,
>     which I started to do, and we also need a good definition of
>     "state" itself. What is that state that gets ported around?
>
>     For (2), I liked your long analysis, but I think there's a shorter
>     way to get where you got, we really don't need to reinvent the Web
>     :) But we can work on that.
>
>
>     Morgaine wrote:
>>     actually writing them would be a good idea.  We've suffered from
>>     this problem here repeatedly, in that documents are just sprung
>>     on us and then it's a major fight to get them back to a mutually
>>     acceptable common base.
>>
>>     It would be infinitely more useful to find the common base
>>     first.  Documents have immense inertia, and the less in them that
>>     needs revising at a core conceptual level, the less time is
>>     wasted by everyone.  A little planning is a major time saver here.
>>
>>
>>     Morgaine.
>>
>>
>>
>>
>>         OK. If more people are interested in this formulation, let's
>>         go ahead with this.
>>         It looks like Meadhbh, who has been the only active draft
>>         writer as far as I can tell (!),  doesn't like/want/? this
>>         formulation, so she is not in a position to write it down. It
>>         is completely unfair of us, and mutually frustrating, to
>>         expect that she is going to write down things that she
>>         doesn't like/want. So someone else needs put their money
>>         where their mouth is, and spend a couple of days writing an
>>         intro draft that's alternative to the one that is currently
>>         active, and that reflects everyone else's expectations on the
>>         existence of [virtual world] application domains of trust.
>>
>>     _______________________________________________ vwrap mailing
>>     list [email-masked] <mailto:[email-masked]>

---

From: Mike Dickson <[email-masked]>
Date: Wed, 22 Sep 2010 13:35:02 -0400

On 09/22/2010 11:28 AM, Cristina Videira Lopes wrote:
> It looks like Meadhbh, who has been the only active draft writer as 
> far as I can tell (!),  doesn't like/want/? this formulation, so she 
> is not in a position to write it down. It is completely unfair of us, 
> and mutually frustrating, to expect that she is going to write down 
> things that she doesn't like/want. So someone else needs put their 
> money where their mouth is, and spend a couple of days writing an 
> intro draft that's alternative to the one that is currently active, 
> and that reflects everyone else's expectations on the existence of 
> [virtual world] application domains of trust.
>
Ok, I'm confused.  Where did you get that Meadbh doesn't agree with the 
approach John presented?  I thought she'd pretty much supported it.  The 
disconnect seems to be around "simulation state" which is pretty vague 
and really needs definition to be discussed.

The big disconnect I've gotten over the last few days and which I still 
don't understand was Meadbh's assertion that VWRAP wasn't about multiple 
virtual worlds inter-operating.  I thought we got past that.

I'll state my position.  I would prefer we focus on a basic set of 
services, payload definitions and wire protocols that provide the 
framework within which co-operating virtual worlds can be built.  It's 
tempting to expand that to include things like transferable simulator 
state, etc, because for a user to get the experience they expect today 
we'll need to eventually deal with that but I prefer to walk first.  I'm 
not personally opposed to adding documents to address additional scope 
over time but if we can produce and initial set that encompasses John's 
list below we'd have accomplished something IMO.

Mike

>>> From:[email-masked]  [mailto:[email-masked]] On Behalf
>>> Cc:[email-masked]
>>>> @OhMeadhbh *http://meadhbh.org/  [email-masked]

---

From: David W Levine <[email-masked]>
Date: Wed, 22 Sep 2010 13:39:18 -0400

So, of course we're building in the web space. I hope nobody is denying
that. In fact if you look at everything described in VWRAP is starts with
an assumption that most services are delivered as REST or REST like
services. I think its safe to say that the people who have been discussing
this for over two years are aware of Roy's work, and have thought about how
REST applies to virtual worlds. REST represents a lot of thinking about how
the web delivers content, and in particular why not to turn the web into a
distributed object model, or a shared state model, but rather to leverage
the observed successful patterns of the web in managing distributed
programming problems.

But..  (There is always a but) The very core thing that a virtual world
does doesn't fit terribly well into the mainstream web model.  The heart of
a virtual world is delivering (and Morgaine's phrase serves very well here)
a visual mashup of things to users 30-60 times a second, updating
continually to reflect the input of  the physical simulation, any user
inputs, and any scripted inputs. Our core problem is taking in the inputs,
deriving the new state and sharing it out to the users. This isn't really
what the web has historically done. The fact that it isn't, that there are
some really interesting distributed system challenges at the very heart of
this, is part of its technical appeal to me.

Life is made harder by the fact that the virtual space is being constantly
asked to accept new things to deal with. Every time an avatar arrives it
brings a set of stuff
which has to be melded into the scenegraph.  Again, we all know this.
Rezing an avatar means adding a bunch of new content to the virtual space,
and it means pushing
it back out to all the observers.

In the traditional web you go to a URL, you do a get, and you get handed a
huge slab of stuff to render.(some of which may require fetches, plugins,
etc.)  In the more dynamic 2.0 style stuff, the stuff you get may include
dynamic elements which fetch and update more stuff. In the virtual worlds
space, we bring to to a fever pitch. we take inputs from all the present
users, from a simulation, including the scripted changes within the
simulation. We then turn around and want to show this to the user.

How do we present this to the user. Well, we currently use Linden's
UDP/http/longpoll tangle. Fine. But. how could we do it?

We could create a video stream and stream it. (WHich isn't very web page
like at all, but has some nice properties)
We could do something like OnLive where we would create a very tailored
stream and deliver it to a client with very specialized coupled inputs (And
life with a lot of
constraints and again isn't very web page like)
We could send a stateless update every frame for the client to render
(Well, with ulimited bandwidth and processor power)
Or.. we could do what we currently do, just cleaner. which, roughly
speaking is send down initial state and then send down a series of updates
to that state. Woah, not
exactly a traditional web page. Worse still.. where do we post the inputs
from the client to the world?

At the same time, we also get to ask "How do we get all the "stuff" into
the region. In Linden's world, the answer is easy. They use a proprietary
protocol and fetch it from
their creaking central servers. In OpenSim, a similar answer obtains. And
for added pain which we have all shared, the current set of clients push
all the stuff related to
the user via the region.

VWRAP attempts to describe nothing more than a set of REST web services
which represent the region and the services. It attempts to leverage what's
been learned from REST, and Linden's system, and in fact OpenSim, to
describe a simple, extensible set of services which can describe: Regions,
Auth services, how to rez and unrez avatars, how to (when we get some
writing down) fetch and manipulate assets, inventory lists and so on.

What you end up with is built deeply on web principals, but not a web page,
but mostly because a virtual world is not, at its heart a web page,but a
set of services collaborating to
share state in a pretty unusual way.

- David
~Zha

---

From: <[email-masked]>
Date: Wed, 22 Sep 2010 13:40:15 -0400

May I suggest we stop arbitrarily trying to define things in emails and come
up with some kind of process into how to define what the first draft
specification should include?  Doesn't W3C have a process on how this works?
I think this is the fundamental problem of this group; we are mixing vision,
requirements, and design in the same email.  We are making design decisions
when we haven't even defined the requirements.

I have so many conflicts with the existing VWRAP document because so many
assumptions they are making about the architecture and design of virtual
worlds that I don't know where to start.

To me there are some very basic and simple things we need, like how John's
email specified.

Teleport to a world.

Authenticate with that world

Import avatar

Import asset

These are the basic verbs that connect the nouns.  We can make any
assumptions about the architecture or structure of a virtual world.  What we
need to define are the external behaviors that it needs to support to allow
interop to occur.

I am focusing on web based distributed virtual worlds, and most of
everything we talk about doesn't fit.  But the verbs like teleporting,
importing do fit.

I like reading all your guys emails but this is getting a little crazy, in
my humble opinion.

K.

 

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Cristina Videira Lopes
Sent: Wednesday, September 22, 2010 1:23 PM
To: Morgaine
Cc: [email-masked]
Subject: Re: [vwrap] Consensus? What exactly should be in the protocol

Definitions here:

Morgaine wrote: 

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

What is "user agent simulation state"?

In VWRAP we have:

*	users (humans driving a "client application");
*	agents (the server-side embodiment of a connection from a client
application);
*	regions that are primarily spatial but may orchestrate many
services;
*	simulations that were traditionally run within a region but which in
VWRAP may be performed by a discrete "simulation service" that could be
external;
*	world state which is primarily held and manipulated by a region
service.

(Note that the above may sound a bit like SL, but it's not really. VWRAP
services can be arranged in numerous different deployment patterns, and an
SL-like configuration is merely one possible deployment out of many.)

To the above should be added that we employ a REST-type protocol for all

Morgaine.

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

Fair, Morgaine.

Morgaine wrote: 

Morgaine.

OK. If more people are interested in this formulation, let's go ahead with
this.
It looks like Meadhbh, who has been the only active draft writer as far as I
can tell (!),  doesn't like/want/? this formulation, so she is not in a
position to write it down. It is completely unfair of us, and mutually
frustrating, to expect that she is going to write down things that she
doesn't like/want. So someone else needs put their money where their mouth
is, and spend a couple of days writing an intro draft that's alternative to
the one that is currently active, and that reflects everyone else's
expectations on the existence of [virtual world] application domains of
trust.

Any takers? 

Hurliman, John wrote: 

This is closer to what I had in my head for VWRAP. Start with the goal of a
portable virtual world presence, and a couple of necessary services fall out
of that:

 
* Type system

John

-----Original Message-----

 

    

developer's

experience.

Life

 

should

words,

 
* type system - in

 

(IMHO)

out.

 
* maintenance - IN

it

on the server side.

 

MOVETO'

to define how the user's

to

* asset access - IN

 

don't

* build tools - OUT

in

this group.

feature

some

specification

 
* event profiles - OUT

 

access

party

avatars

 
anyway... thoughts?

 

* search - OUT

* teleport - IN
 
* virtual currency - OUT
 
* world map - OUT
 
* "space server" - IN

 
-cheers
-meadhbh

 

  _____  

 

  _____

---

From: Mike Dickson <[email-masked]>
Date: Wed, 22 Sep 2010 13:43:37 -0400

An excellent synopsis.  It could make a great intro for a document 
describing what VWRAP is trying to do....

Mike

On 09/22/2010 01:39 PM, David W Levine wrote:
>
> So, of course we're building in the web space. I hope nobody is 
> denying that. In fact if you look at everything described in VWRAP is 
> starts with an assumption that most services are delivered as REST or 
> REST like services. I think its safe to say that the people who have 
> been discussing this for over two years are aware of Roy's work, and 
> have thought about how REST applies to virtual worlds. REST represents 
> a lot of thinking about how the web delivers content, and in 
> particular why not to turn the web into a
> distributed object model, or a shared state model, but rather to 
> leverage the observed successful patterns of the web in managing 
> distributed programming problems.
>
> does doesn't fit terribly well into the mainstream web model. The 
> heart of a virtual world is delivering (and Morgaine's phrase serves 
> very well here) a visual mashup of things to users 30-60 times a 
> second, updating continually to reflect the input of the physical 
> simulation, any user
> inputs, and any scripted inputs. Our core problem is taking in the 
> inputs, deriving the new state and sharing it out to the users. This 
> isn't really what the web has historically done. The fact that it 
> isn't, that there are some really interesting distributed system 
> challenges at the very heart of this, is part of its technical appeal 
> to me.
>
> Life is made harder by the fact that the virtual space is being 
> constantly asked to accept new things to deal with. Every time an 
> avatar arrives it brings a set of stuff
> Rezing an avatar means adding a bunch of new content to the virtual 
> space, and it means pushing
> In the traditional web you go to a URL, you do a get, and you get 
> handed a huge slab of stuff to render.(some of which may require 
> fetches, plugins, etc.) In the more dynamic 2.0 style stuff, the stuff 
> you get may include dynamic elements which fetch and update more 
> stuff. In the virtual worlds space, we bring to to a fever pitch. we 
> take inputs from all the present users, from a simulation, including 
> the scripted changes within the simulation. We then turn around and 
> want to show this to the user.
>
> We could create a video stream and stream it. (WHich isn't very web 
> page like at all, but has some nice properties)
> We could do something like OnLive where we would create a very 
> tailored stream and deliver it to a client with very specialized 
> coupled inputs (And life with a lot of
> speaking is send down initial state and then send down a series of 
> updates to that state. Woah, not
> exactly a traditional web page. Worse still.. where do we post the 
> inputs from the client to the world?
>
> At the same time, we also get to ask "How do we get all the "stuff" 
> into the region. In Linden's world, the answer is easy. They use a 
> proprietary protocol and fetch it from
> their creaking central servers. In OpenSim, a similar answer obtains. 
> And for added pain which we have all shared, the current set of 
> clients push all the stuff related to
> the user via the region.
>
> VWRAP attempts to describe nothing more than a set of REST web 
> services which represent the region and the services. It attempts to 
> leverage what's been learned from REST, and Linden's system, and in 
> fact OpenSim, to describe a simple, extensible set of services which 
> can describe: Regions, Auth services, how to rez and unrez avatars, 
> how to (when we get some writing down) fetch and manipulate assets, 
> inventory lists and so on.
>
> What you end up with is built deeply on web principals, but not a web 
> page, but mostly because a virtual world is not, at its heart a web 
> page,but a set of services collaborating to

---

From: Meadhbh Hamrick <[email-masked]>
Date: Wed, 22 Sep 2010 10:48:13 -0700

right, but if we're going to put "web like" in a normative document we
need to define it better than using the ostensive definition.

specifically what features of the web are we trying to emulate? the
ability to type in a URL? that's a client issue, not a protocol issue.
HTTP knows absolutely nothing about how the client application decided
which host to connect to or what path to ask for.

my guess is you're saying that an overall solution should be:

a. as easy as a web browser to use, and it should be easy to point to
different instances of virtual world regions that are owned and
operated by completely different people (just like it is on the web.)

b. the protocols themselves should be largely agnostic regarding the
content they carry. HTTP for instance, will gladly transport XML, HTML
(of multiple versions), JPEG, AU, etc. etc. Any protocol we come up
with should have the same feature. There should be no "lock in" to
proprietary formats in an open standard.

c. the client mediates different trust domains.

and i'm down with all of these ideas with the following caveats:

1. client issue are out of scope. i'll stop harping on this since i
_think_ we have general agreement on this point. that being said,
maybe there's room for an informative or best practices document
describing the user experience? i'm down with that as long as we all
agree to respect each other's use cases. i would like to ask that we
investigate whether that task should be moved to an IRTG group though.
i think it would be a hard sell to the IAB / IESG to create a
NORMATIVE document that described client issues like that. i could be
wrong, and if i am, i'll shut up about it.

2. there are several virtual worlds out there that practice what david
refers to as "federated trust" or some such. Second Life is an
example. InWorldz is another. we should not make a protocol that makes
this use case impossible. that being said, i am TOTALLY down with
specifying a protocol that can also be used for my use case. and heck,
i think if we do it right, we can make a protocol that works on P2P
overlays, even though no one here is bouncing up and down saying
they're going to implement one anytime soon.

so i think after this big kvetch-fest, we're all pretty much on the
same page. we all respect each other's use cases. i'm not trying to
shoo anyone away when they talk about client issues, but it is a
simple fact that this group was not chartered to address them. if we,
as a group, want to address them, that's fine, but we would probably
want to recharter to make it explicitly clear we're including that in
the group's scope.

-cheers
-meadhbh

On Wed, Sep 22, 2010 at 10:22 AM, Cristina Videira Lopes
<[email-masked]> wrote:
> users (humans driving a "client application");
> agents (the server-side embodiment of a connection from a client
> application);
> regions that are primarily spatial but may orchestrate many services;
> simulations that were traditionally run within a region but which in VWRAP
> may be performed by a discrete "simulation service" that could be external;
> world state which is primarily held and manipulated by a region service.
>
>>> as I can tell (!),  doesn't like/want/? this formulation, so she is not in a

---

From: Cristina Videira Lopes <[email-masked]>
Date: Wed, 22 Sep 2010 11:07:56 -0700

All the limitations that you mention about the Web architecture not 
being enough to support virtual world applications have been muted by 
HTML5. Additionally, CORS now allows for true client-side mashups.
But even without these two things, you can build non-web-browser clients 
that follow the general principles but that do special things for the 
real-time updates -- basically, the general concept of 
JavaScript+WebSockets done in whatever other way you like: different 
programming language, different protocol,...

The really important architectural principle, though, and one that is 
unlikely to be let go, is that the use of WebSockets, the data formats 
that flow through them, and the use of CORS, are decisions that pertain 
to *each* virtual world application, it's not something that is imposed 
on all VWs by web standards -- it comes as JavaScript sent by the 
server! They are *implementation options* -- very valid options, I must 
add, but options nevertheless. What you are trying to do here is to 
dictate that all virtual world applications MUST use some protocol for 
renderer -- server interactions, down to the data formats, and MUST use 
capabilities for mashing things up, or else... they can't interoperate.

You can dictate that. But then this will be completely irrelevant in a 
couple of years when WebGL is actually usable or when Google finishes 
their virtual machine for running safe native code on browsers.

---

From: Morgaine <[email-masked]>
Date: Wed, 22 Sep 2010 19:12:56 +0100

Oh I think I see, Crista.  If I'm right then it's just your language that
differs a bit from ours, which shouldn't be too surprising. :-)

Judging by the post you linked, your "*user agent simulation state*" seems
to be simply our "*agent*", or if there is an in-world representation too,
then it's our "*agent + avatar*".

The avatar is (typically) a visual representation of the agent, but the
visual representation is of course performed in the client, not the server.
In VWRAP the media elements that the client requires to draw an avatar comes
from *asset services*, and proxying by the region as we see in SL would be a
highly suboptimal deployment pattern, albeit a valid one.  Normally assets
would travel straight from asset services to client applications to make the
most of the massively parallel paths of the Internet.  (Scalability is a
primary concern for us.)  The avatar representation is not referred to as
simulation in VWRAP.

The region's actual simulation service does perform *physics simulation* of
course, which comprises both environmental physics (gravity, mass, inertia)
and collision physics (bounding boxes, terrain), but that only affects
avatar position and orientation, not visual representation.

I think that straightens out the terminology differences in your phrase.
But VWRAP is not involved in standardizing avatars, as that would be quite
futile.  Avatars will be as varied as the asset services that carry the
components out of which avatars are represented.

We would expect industry standard formats to be used for representing
avatars, such as Collada.  Our protocol would be concerned merely with
placing agents in-world and, optionally, triggering the start of avatar
instantiation ("rezzing") in all participating client applications.  There's
a bit more to it, but that's the gist.

Does that make sense in an OpenSimulator context?  (I'm actually very
surprised to see that our terminologies differ so much --- we should have
come together a long time ago. :P)

Morgaine.

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

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

> On Wed, Sep 22, 2010 at 5:12 PM, Cristina Videira Lopes <[email-masked]
> > wrote:
>
>>
>    - *simulations* that were traditionally run within a region but which
>    in VWRAP may be performed by a discrete "*simulation service*" that
>    could be external;
> services can be arranged in numerous different *deployment patterns*, and
> an SL-like configuration is merely one possible deployment out of many.)
>
> On Wed, Sep 22, 2010 at 5:12 PM, Cristina Videira Lopes <[email-masked]
> > wrote:
>
>>  Fair, Morgaine.
>> On Wed, Sep 22, 2010 at 4:28 PM, Cristina Videira Lopes <
>> [email-masked]> wrote:
>>

---

From: Meadhbh Hamrick <[email-masked]>
Date: Wed, 22 Sep 2010 11:50:25 -0700

christina,

i think you may be missing the point of capabiliies a bit. they're in
the mix here so we can avoid the confused deputy problem and have
"loosely coupled" collections of services. CORS does allow you to do
mashups in a user agent, but CORS in and of itself says nothing about
trust with respect to the server side.

in other words, if i want to create an application that is a composite
of two services, each of which touches "sensitive" data, i have to
have a way for the client to authorize itself to both services.

you can do this with something like SAML and you can use OAuth as a
way to carry proof of authorization. but you would still need trust
relationships between the two services for this to work. capabilities
allow us to use a "transitive trust" model that reduces the
requirement for a federated identity / trust model.

and i like that idea.

however, you can compose something like SAML + OAuth with
capabilities, but you can't go the other way.

SAML and OAuth are GREAT technologies to use for certain problems, but
the world is more than a browser or client. some use cases require
services to either trust each other (independently of trust stitched
together by the client) or to trust the people they trust without a
pre-existing direct-trust relationship.

so it's all about whom you trust. my take on the tourist model is that
it's the client that decides whom to trust. and my take on the
HyperGrid model is that it's the simulator that decides whom to trust.
what we want to build with the use of capabilities is the generic
ability of an auth service that decides whom to trust, even if there
is not an existing trust relationship between the client and the
non-auth service.

i wonder if it's possible to define RESTful VWRAP resources
independently of them being behind capabilities. if you're really down
with using traditional web auth, this might be an answer.

we could define a cap based service establishment protocol flow, but
make it independent of the use of other defined resources. so if they
service establishment were defined with RFC XXXX and some other
service were defined in RFC YYYY, you could deploy a RFC YYYY service
without the benefits of RFC XXXX. it should be straight-forward to
even code this.

if you really have a use case for direct-trust only, laissez les
bontemps roullez!

does this make sense?

-cheers
-meadhbh

On Wed, Sep 22, 2010 at 11:07 AM, Cristina Videira Lopes
<[email-masked]> wrote:
> All the limitations that you mention about the Web architecture not being
> enough to support virtual world applications have been muted by HTML5.
> Additionally, CORS now allows for true client-side mashups.
> real-time updates -- basically, the general concept of JavaScript+WebSockets
> done in whatever other way you like: different programming language,
> different protocol,...
>
> unlikely to be let go, is that the use of WebSockets, the data formats that
> flow through them, and the use of CORS, are decisions that pertain to *each*
> virtual world application, it's not something that is imposed on all VWs by
> web standards -- it comes as JavaScript sent by the server! They are
> *implementation options* -- very valid options, I must add, but options
> nevertheless. What you are trying to do here is to dictate that all virtual
> world applications MUST use some protocol for renderer -- server
> interactions, down to the data formats, and MUST use capabilities for
> mashing things up, or else... they can't interoperate.
>
> couple of years when WebGL is actually usable or when Google finishes their
> virtual machine for running safe native code on browsers.
>
>
>
> David W Levine wrote:
>>
>> that. In fact if you look at everything described in VWRAP is starts with an
>> assumption that most services are delivered as REST or REST like services. I
>> think its safe to say that the people who have been discussing this for over
>> two years are aware of Roy's work, and have thought about how REST applies
>> to virtual worlds. REST represents a lot of thinking about how the web
>> delivers content, and in particular why not to turn the web into a
>> does doesn't fit terribly well into the mainstream web model. The heart of a
>> virtual world is delivering (and Morgaine's phrase serves very well here) a
>> visual mashup of things to users 30-60 times a second, updating continually
>> to reflect the input of the physical simulation, any user
>> for added pain which we have all shared, the current set of clients push all
>> the stuff related to
>> the user via the region.
>>
>> page, but mostly because a virtual world is not, at its heart a web page,but
>> a set of services collaborating to

---

From: Morgaine <[email-masked]>
Date: Wed, 22 Sep 2010 19:58:53 +0100

Indeed, standardizing on data formats would result in a protocol that is
obsolete before it's released.  Which is why VWRAP doesn't do that. :P

Instead (using my own form of words here to try to make this more
understandable), VWRAP is concerned with "*gluing together*" services in a
highly dynamic and flexible manner.  Those services can be switched and
extended at a moment's notice, under the control of the VWRAP protocol, not
only to extend the feature set but also to alter the particular deployment
pattern in use, if this is desired.

VWs are expected to evolve and change drastically over the next several
years, so adaptability in a world of continuous change is paramount, so we
have stressed the need for *extensibility* a lot.

The following should really go without saying, but I'll say it anyway in
light of a recent comment --- VWRAP extensibility does not mean "go back to
the IETF for another round of standardization".  It means that outside of a
small neutral core, the protocol is dynamically extensible on demand,
specifically by hooking in improved services, or indeed totally new ones.
Revision of the core protocol should only be required if the old one is
found to be incapable of adequate orchestration of improved services.  To
the best of our ability, we will try to make this unnecessary.

Think of VWRAP as the Unix shell --- you rarely need to change it!  The
shell is just the glue by which you assemble suites of processes to do the
actual work in Unix.  In VWRAP, the VWRAP protocol glues together VWRAP
services in a similar fashion.

There's a lot of work to be done before this becomes a reality of course.

Morgaine.

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

---

From: Cristina Videira Lopes <[email-masked]>
Date: Wed, 22 Sep 2010 11:59:50 -0700

> their virtual machine for running safe native code on browsers.
...or when server-side streaming goes mainstream, and being in a virtual 
world is as simple as running a video player plus a few 
JavaScript/native back channels to the server.

First point is: according to the Web principles, each web application 
controls 100% what and how the client gets via this really powerful 
concept of hypermedia. It is unlikely that the world is going to adopt a 
standard that forces implementers to take several steps back on this 
kind of autonomy. The diversity is what gives service providers an edge.

The second point is: when we have all that variety of viewer 
implementations that are all equally accepted by the web browser, we are 
still to cope with portability of user agent simulation state between 
those worlds -- and that's the bottom line for interoperability of 
virtual worlds on the Web. I'm interested in this, because it's much 
more foundational than the variety of virtual world implementation options.

---

From: Cristina Videira Lopes <[email-masked]>
Date: Wed, 22 Sep 2010 12:09:26 -0700

Perhaps we should all step back until *someone* sends a draft that 
actually captures this?
Which is not the current draft :)

Morgaine wrote:
> Indeed, standardizing on data formats would result in a protocol that 
> is obsolete before it's released.  Which is why VWRAP doesn't do that. :P
>
> understandable), VWRAP is concerned with "/gluing together/" services 
> in a highly dynamic and flexible manner.  Those services can be 
> switched and extended at a moment's notice, under the control of the 
> VWRAP protocol, not only to extend the feature set but also to alter 
> the particular deployment pattern in use, if this is desired.
>
> VWs are expected to evolve and change drastically over the next 
> several years, so adaptability in a world of continuous change is 
> paramount, so we have stressed the need for /extensibility/ a lot.
>
> The following should really go without saying, but I'll say it anyway 
> in light of a recent comment --- VWRAP extensibility does not mean "go 
> back to the IETF for another round of standardization".  It means that 
> outside of a small neutral core, the protocol is dynamically 
> extensible on demand, specifically by hooking in improved services, or 
> indeed totally new ones.  Revision of the core protocol should only be 
> required if the old one is found to be incapable of adequate 
> orchestration of improved services.  To the best of our ability, we 
> will try to make this unnecessary.
>
> Think of VWRAP as the Unix shell --- you rarely need to change it!  
> The shell is just the glue by which you assemble suites of processes 
> to do the actual work in Unix.  In VWRAP, the VWRAP protocol glues 
> together VWRAP services in a similar fashion.
>
>     All the limitations that you mention about the Web architecture
>     not being enough to support virtual world applications have been
>     muted by HTML5. Additionally, CORS now allows for true client-side
>     mashups.
>     But even without these two things, you can build non-web-browser
>     clients that follow the general principles but that do special
>     things for the real-time updates -- basically, the general concept
>     of JavaScript+WebSockets done in whatever other way you like:
>     different programming language, different protocol,...
>
>     The really important architectural principle, though, and one that
>     is unlikely to be let go, is that the use of WebSockets, the data
>     formats that flow through them, and the use of CORS, are decisions
>     that pertain to *each* virtual world application, it's not
>     something that is imposed on all VWs by web standards -- it comes
>     as JavaScript sent by the server! They are *implementation
>     options* -- very valid options, I must add, but options
>     nevertheless. What you are trying to do here is to dictate that
>     all virtual world applications MUST use some protocol for renderer
>     -- server interactions, down to the data formats, and MUST use
>     You can dictate that. But then this will be completely irrelevant
>     in a couple of years when WebGL is actually usable or when Google
>     finishes their virtual machine for running safe native code on
>     browsers.
>
>
>
>
>     David W Levine wrote:
>
>
>         So, of course we're building in the web space. I hope nobody
>         is denying that. In fact if you look at everything described
>         in VWRAP is starts with an assumption that most services are
>         delivered as REST or REST like services. I think its safe to
>         say that the people who have been discussing this for over two
>         years are aware of Roy's work, and have thought about how REST
>         applies to virtual worlds. REST represents a lot of thinking
>         about how the web delivers content, and in particular why not
>         to turn the web into a
>         distributed object model, or a shared state model, but rather
>         to leverage the observed successful patterns of the web in
>         managing distributed programming problems.
>
>         But.. (There is always a but) The very core thing that a
>         virtual world does doesn't fit terribly well into the
>         mainstream web model. The heart of a virtual world is
>         delivering (and Morgaine's phrase serves very well here) a
>         visual mashup of things to users 30-60 times a second,
>         updating continually to reflect the input of the physical
>         simulation, any user
>         inputs, and any scripted inputs. Our core problem is taking in
>         the inputs, deriving the new state and sharing it out to the
>         users. This isn't really what the web has historically done.
>         The fact that it isn't, that there are some really interesting
>         distributed system challenges at the very heart of this, is
>         part of its technical appeal to me.
>
>         Life is made harder by the fact that the virtual space is
>         being constantly asked to accept new things to deal with.
>         Every time an avatar arrives it brings a set of stuff
>         which has to be melded into the scenegraph. Again, we all know
>         this. Rezing an avatar means adding a bunch of new content to
>         the virtual space, and it means pushing
>         In the traditional web you go to a URL, you do a get, and you
>         get handed a huge slab of stuff to render.(some of which may
>         require fetches, plugins, etc.) In the more dynamic 2.0 style
>         stuff, the stuff you get may include dynamic elements which
>         fetch and update more stuff. In the virtual worlds space, we
>         bring to to a fever pitch. we take inputs from all the present
>         users, from a simulation, including the scripted changes
>         within the simulation. We then turn around and want to show
>         this to the user.
>
>         How do we present this to the user. Well, we currently use
>         Linden's UDP/http/longpoll tangle. Fine. But. how could we do it?
>
>         We could create a video stream and stream it. (WHich isn't
>         very web page like at all, but has some nice properties)
>         tailored stream and deliver it to a client with very
>         specialized coupled inputs (And life with a lot of
>         We could send a stateless update every frame for the client to
>         render (Well, with ulimited bandwidth and processor power)
>         Or.. we could do what we currently do, just cleaner. which,
>         roughly speaking is send down initial state and then send down
>         a series of updates to that state. Woah, not
>         exactly a traditional web page. Worse still.. where do we post
>         the inputs from the client to the world?
>
>         At the same time, we also get to ask "How do we get all the
>         "stuff" into the region. In Linden's world, the answer is
>         easy. They use a proprietary protocol and fetch it from
>         their creaking central servers. In OpenSim, a similar answer
>         obtains. And for added pain which we have all shared, the
>         current set of clients push all the stuff related to
>         the user via the region.
>
>         services which represent the region and the services. It
>         attempts to leverage what's been learned from REST, and
>         Linden's system, and in fact OpenSim, to describe a simple,
>         extensible set of services which can describe: Regions, Auth
>         services, how to rez and unrez avatars, how to (when we get
>         some writing down) fetch and manipulate assets, inventory
>         lists and so on.
>
>         What you end up with is built deeply on web principals, but
>         not a web page, but mostly because a virtual world is not, at
>         its heart a web page,but a set of services collaborating to

---

From: Meadhbh Hamrick <[email-masked]>
Date: Wed, 22 Sep 2010 12:21:25 -0700

> obsolete before it's released.  Which is why VWRAP doesn't do that. :P

um. hate to say this, but yes, we did commit to defining a few data
formats (look at the charter.) i think we said we were going to do
asset and avatar data formats.

but the MPEG guys are working on a standard avatar format. assuming
that format is free of IPR encumbrance, i'm totally down with
considering it as our standard format and then defining it by
reference.

also, proposals i've seen for the "format" for assets have all been
resources defined by LLIDL or DSD, so they're extensible and they're a
little more "abstract" than what we might normally call a "data
format." (though we do define serializations.)

but we're TOTALLY not going to try to re-invent texture formats, audio
data format and i'm assuming there are some open animation formats out
there somewhere.

> understandable), VWRAP is concerned with "gluing together" services in a

cool. sounds great. i want to support your goal of stitching your
services together in the way you want to stitch them together as long
as you support my goal of doing it the way i want to stitch my
services together.

we're starting to get a little abstract here, let's all keep our heads
and remember that at some point john and i are going to have to code
this stuff.

> have stressed the need for extensibility a lot.

yeah. but maybe the thing to do is define a small standard now and
then try to figure out what's wrong with it as the world changes? you
have to be careful with how much extensibility you throw into
something, otherwise you spend all of your time coding for use cases
that will never emerge.

still.. yeah.. extensibility in general is good.

> the best of our ability, we will try to make this unnecessary.

so you're opposed to the "boil the ocean one thimble at a time" approach?

<insert incendiary comment here that leads to a flame war where we
talk past each other for a couple days then eventually cool down and
start having rational conversations again>

this sounds like you don't like the idea of starting small,
standardize what we can all agree to and then move on? is that
possibly right?

what's wrong with standardizing something, deploying it, figuring out
what's wrong with it and then trying again if we don't get traction?

> services in a similar fashion.

yes. i've used the example of SIP and SS7. they're protocols that "set
up" calls but can be used with different specific bearers.

but by the same token, both SIP and SS7 are designed for a relatively
small, and IMHO underspecified problem domain.

i REALLY don't want VWRAP to become the Advanced Intelligent Network
initiative of virtual worlds, otherwise it will be useless.

> On Wed, Sep 22, 2010 at 7:07 PM, Cristina Videira Lopes <[email-masked]>
> wrote:
>>
>>> inputs, deriving the new state and sharing it out to the users. This isn't
>>> really what the web has historically done. The fact that it isn't, that
>>> there are some really interesting distributed system challenges at the very
>>> heart of this, is part of its technical appeal to me.
>>>
>>> constantly asked to accept new things to deal with. Every time an avatar
>>> arrives it brings a set of stuff
>>> In the traditional web you go to a URL, you do a get, and you get handed
>>> a huge slab of stuff to render.(some of which may require fetches, plugins,

---

From: Meadhbh Hamrick <[email-masked]>
Date: Wed, 22 Sep 2010 12:36:51 -0700

On Wed, Sep 22, 2010 at 11:59 AM, Cristina Videira Lopes
<[email-masked]> wrote:
> world is as simple as running a video player plus a few JavaScript/native
> back channels to the server.
>
> controls 100% what and how the client gets via this really powerful concept
> of hypermedia. It is unlikely that the world is going to adopt a standard
> that forces implementers to take several steps back on this kind of
> autonomy. The diversity is what gives service providers an edge.

hold on there! you just gave two completely opposing examples. if i
have a video player that's receiving raster lines from a distant game
server, that's TOTALLY the opposite of a client having complete
control over it's hypermedia input. if i simply started streaming an
OnLive session of someone doing SecondLife in a flash based video
player, there's absolutely no way to guarantee that the data used to
create the scene would be available to the client.

> The second point is: when we have all that variety of viewer implementations
> that are all equally accepted by the web browser, we are still to cope with
> portability of user agent simulation state between those worlds -- and
> that's the bottom line for interoperability of virtual worlds on the Web.
> I'm interested in this, because it's much more foundational than the variety
> of virtual world implementation options.

also... the virtual world is not a web application.

if you look at typical web apps, the mashing up is usually done at the
server side, turned into HTML and then sent to the browser.

we're starting to see a lot more apps where JavaScript is used to do
mashups in the client, but...

VWRAP was chartered to work on server-authoritative worlds (like
Second Life and OpenSim.) that means there's a lot of state in the
simulator. it sounds like you want to open this state up and push its
simulation to the edge of the network (and thus support
co-simulation.)

did i read that right? did you really just say that virtual worlds are
client web apps?

---

From: Meadhbh Hamrick <[email-masked]>
Date: Wed, 22 Sep 2010 12:36:38 -0700

i think morgaine has mentioned she's not going to write a draft.

i'll publish another version of the intro that addresses your earlier
feedback, but i still think we need some more cussing and discussing
before we can all agree that the focus of this group is not what we
originally chartered, but for dropping data formats and extending the
scope.

i think i agree with morgaine that VWRAP should definitely be about
stitching services together. i like it when servers stitch things
together, so that's going in the mix. it sounds like you and morgaine
like stitching things together at the client side. i'll make a stab at
what i think you're saying. don't freak if i get it wrong. your
previous email that listed all the things you had issues with was
PERFECT. i don't agree with everything you said, but i think your
concerns we well formed.

-cheers
-meadhbh

On Wed, Sep 22, 2010 at 12:09 PM, Cristina Videira Lopes
<[email-masked]> wrote:
> Perhaps we should all step back until *someone* sends a draft that actually
> captures this?

---

From: Cristina Videira Lopes <[email-masked]>
Date: Wed, 22 Sep 2010 13:07:08 -0700

Meadhbh Hamrick wrote:
> control over it's hypermedia input. 
What? %-)
The *server* has control, not the client. The server decides whether to 
provide a VW via video streaming, whether to send out a native piece of 
code that represents the "viewer" or whether to send JavaScript. The 
client simply accepts whatever the server sends.

If the VWRAP protocol says: "servers send capabilities of assets to 
clients and clients pull the assets by invoking those capabilities and 
then mash it up and render it" you're doing very strong assumptions 
about the viewer; you're basically excluding the video player (because 
there is no asset data to pull). Point is: capabilities (or CORS) are an 
implementation option of the application. They are not the only option, 
and they are not fundamental for interoperability -- at least certainly 
not the asset-related capabilities.

This was my comment to one of the sections where you go into explaining 
this mashup.

> if i simply started streaming an
OpenSimulator does not impose anything wrt the client. The client 
representation on the server is a plugin. Therefore, it can easily 
support JavaScript viewers, which is something that I am more and more 
interested in.

> did i read that right? did you really just say that virtual worlds are

I'm saying that virtual worlds are web applications. I don't know what 
"client web apps" are. Are you saying JavaScript-heavy? If so, yes, 
maybe, if they don't use video streaming. Like Facebook, but with a 3D 
viewer coming in to the client as hypermedia -- if we are to use regular 
web browsers. We can use phat clients, too, that hard-code some viewer.

This doesn't work very well today, but it will be here in a couple of 
years.

---

From: David W Levine <[email-masked]>
Date: Wed, 22 Sep 2010 16:14:10 -0400

So. I guess I'm deeply confused. The Remit of WRAP, for a lot of reasons
is:
"SecondLife Like" worlds. Which is to say worlds in which there is a server
from which one gets the state of the virtual simulation.  Which is to say
that
a client connects, and says "Please place an avatar here and tell me what's
happening
around here"  (which implies a whole bunch of other stuff, but put that to
one side for a moment)

The vwrap specs have always marked the client as web endpoint which sends
requests and gets back responses. There has been some interesting
discussion and
debate about to efficiently keep a client informed about the scenegraph
they are
interested int, but it rather does follow the web model.

"Dear server, I want to know about X"
"Dear client, here is what's at X"

with the fun of "Oh, and here is what's at X now, and Now, and Now, and
Now" because the scenegraph
is constantly changing.  It doesn't tell the client what to do, and we've
talked at length about how to
use content negotation, mime types and such to let the client and the
server do web style negotiation about
what the client wants to see. (and this is very much marked as extensible,
exactly as Morgaine's been repeating)

Further, the "Client/Sim" part is, in many ways, the least interesting part
of the spec. The ongoing discussion has
always been that for the time being it just would re-use Linden's basic
pipes, not because they were lovely
but because they worked, there is content, there is a clienbt, there is
OpenSim, and it's useful to move forward.

The heavy lifting has always been in the form of "I have a shape X, and a
set of parts attached to me" which I want to bring
with me to "virtual space X" That's only related to the client to the
extent that at some point, all the clients connected to
a region need to share a set of things they can display (with content
negotiation mixed in) or the shared experience
becomes "Woah, John's a dragon? He looks like a blue blob to me"

I think there's a huge amount of "assuming"  going on here, and it's
frustrating as all get out.

- David
~Zha

  From:       Cristina Videira Lopes <[email-masked]>                                                                           
                                                                                                                                   
  To:         [email-masked]                                                                                                    
                                                                                                                                   
  Cc:         David W Levine/Watson/IBM@IBMUS, [email-masked], [email-masked]                                              
                                                                                                                                   
  Date:       09/22/2010 03:00 PM

---

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

>>> concept
> provide a VW via video streaming, whether to send out a native piece of code
> that represents the "viewer" or whether to send JavaScript. The client
> simply accepts whatever the server sends.
>
> If the VWRAP protocol says: "servers send capabilities of assets to clients
> and clients pull the assets by invoking those capabilities and then mash it
> up and render it" you're doing very strong assumptions about the viewer;
> you're basically excluding the video player (because there is no asset data
> to pull). Point is: capabilities (or CORS) are an implementation option of
> the application. They are not the only option, and they are not fundamental
> for interoperability -- at least certainly not the asset-related
> capabilities.
>
> This was my comment to one of the sections where you go into explaining this
> mashup.
>

my point is that if you're going to depend on CORS in the client to do
app mashup, and one of the servers sends you HTML that includes a
flash plugin that only sends video of a distantly rendered SecondLife
app window, you're going to have a hard time picking apart the data
that went into composing the video by services from other servers.

---

From: <[email-masked]>
Date: Wed, 22 Sep 2010 16:30:00 -0400

The protocol will only be obsolete if it is not designed to support new
formats or varied formats, or have any discovery or caps ability.

Maybe others are working on some avatar format, I don't know of one.  But
here is kind of thing I am working on; it isn't fancy but probably handles
most things we see today.

Just as an example Avatar Manifest

1.	List of Objects
2.	List of attachment points
3.	References to actual physical objects
4.	List of animations
5.	Animation name mapping to public capabilities specification
6.	List of gesture or others script based capabilities.

It is really true that VWRAP will not have a specification on the avatar.
How can one avatar go to another space without that?  How will I know how to
expose my avatar to another space without it?

Regards,

K.

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Cristina Videira Lopes
Sent: Wednesday, September 22, 2010 3:09 PM
To: Morgaine
Cc: [email-masked]
Subject: Re: [vwrap] Consensus? What exactly should be in the protocol

Morgaine wrote: 

Morgaine.

David W Levine wrote:

But.. (There is always a but) The very core thing that a virtual world does
doesn't fit terribly well into the mainstream web model. The heart of a

Life is made harder by the fact that the virtual space is being constantly
asked to accept new things to deal with. Every time an avatar arrives it
brings a set of stuff
which has to be melded into the scenegraph. Again, we all know this. Rezing
an avatar means adding a bunch of new content to the virtual space, and it
means pushing
it back out to all the observers.

We could create a video stream and stream it. (WHich isn't very web page
like at all, but has some nice properties)
We could do something like OnLive where we would create a very tailored
stream and deliver it to a client with very specialized coupled inputs (And
life with a lot of
constraints and again isn't very web page like)
We could send a stateless update every frame for the client to render (Well,
with ulimited bandwidth and processor power)
Or.. we could do what we currently do, just cleaner. which, roughly speaking
is send down initial state and then send down a series of updates to that
state. Woah, not
exactly a traditional web page. Worse still.. where do we post the inputs
from the client to the world?

At the same time, we also get to ask "How do we get all the "stuff" into the
region. In Linden's world, the answer is easy. They use a proprietary
protocol and fetch it from
their creaking central servers. In OpenSim, a similar answer obtains. And
for added pain which we have all shared, the current set of clients push all
the stuff related to
the user via the region.

What you end up with is built deeply on web principals, but not a web page,
but mostly because a virtual world is not, at its heart a web page,but a set
of services collaborating to
share state in a pretty unusual way.

- David
~Zha

 

  _____

---

From: Cristina Videira Lopes <[email-masked]>
Date: Wed, 22 Sep 2010 13:32:59 -0700

> that went into composing the video by services from other servers.
Exactly. So you don't pick it apart. And that's a decision of whoever 
wrote the web application. It's not anyone's business.

---

From: Cristina Videira Lopes <[email-masked]>
Date: Wed, 22 Sep 2010 13:33:26 -0700

I think this is great, and we are on the same page.
But the drafts don't reflect this, and a lot of language in these emails 
also don't reflect this. They are full of intrusions into the 
renderer-server protocol and into the design of the virtual world itself.

David W Levine wrote:
>
> So. I guess I'm deeply confused. The Remit of WRAP, for a lot of 
> reasons is:
> from which one gets the state of the virtual simulation. Which is to 
> say that
> a client connects, and says "Please place an avatar here and tell me 
> what's happening
> around here" (which implies a whole bunch of other stuff, but put that 
> to one side for a moment)
>
> debate about to efficiently keep a client informed about the 
> scenegraph they are
> with the fun of "Oh, and here is what's at X now, and Now, and Now, 
> and Now" because the scenegraph
> is constantly changing. It doesn't tell the client what to do, and 
> we've talked at length about how to
> what the client wants to see. (and this is very much marked as 
> extensible, exactly as Morgaine's been repeating)
>
> Further, the "Client/Sim" part is, in many ways, the least interesting 
> part of the spec. The ongoing discussion has
> always been that for the time being it just would re-use Linden's 
> basic pipes, not because they were lovely
> but because they worked, there is content, there is a clienbt, there 
> is OpenSim, and it's useful to move forward.
>
> The heavy lifting has always been in the form of "I have a shape X, 
> and a set of parts attached to me" which I want to bring
> Inactive hide details for Cristina Videira Lopes ---09/22/2010 
> 03:00:13 PM---Cristina Videira Lopes wrote: > You can dictate 
> thCristina Videira Lopes ---09/22/2010 03:00:13 PM---Cristina Videira 
> Lopes wrote: > You can dictate that. But then this will be completely 
> irrelevant in
>
>
> From: 	
> Cristina Videira Lopes <[email-masked]>
>
> To: 	
> [email-masked]
>
> Cc: 	
> David W Levine/Watson/IBM@IBMUS, [email-masked], [email-masked]
>
> Date: 	
> 09/22/2010 03:00 PM
>
> Subject: 	
> Re: [vwrap] Consensus? What exactly should be in the protocol
>

---

From: Meadhbh Hamrick <[email-masked]>
Date: Wed, 22 Sep 2010 13:35:49 -0700

On Wed, Sep 22, 2010 at 1:30 PM,  <[email-masked]> wrote:

>  How can one avatar go to another space without that?  How will I know how
> to expose my avatar to another space without it?

well. we did actually list a document called 'Avatar Format' in the
group charter.

i honestly don't know where morgaine go the idea we weren't going to work on it.

however... other people are working on avatar format standards, it's
entirely within the realm of possibility that this group may decide
simply to adopt a format defined by another standards development
organization

---

From: Morgaine <[email-masked]>
Date: Wed, 22 Sep 2010 21:37:38 +0100

On Wed, Sep 22, 2010 at 8:36 PM, Meadhbh Hamrick <[email-masked]>wrote:

I'm certainly not going to write a draft before there is good agreement on
what should be in it, and until that agreement is on a forward-looking
protocol that takes us significantly beyond where we currently are today in
SL and OpenSimulator.

We've wasted 2 years already in this process because people have dived in
and written drafts with complete disregard of the needs of interop and with
very little future vision, and the result is, not surprisingly, widespread
disagreement and document rejection.

It's not good enough.

The current fighting needs to quieten down and focus on technical issues so
that we can gather around a common technical analysis and collaborate as
engineers and professionals do.  Currently everyone is talking about
something different, and much of it doesn't even have anything to do with
the VWRAP model.

Morgaine.

On Wed, Sep 22, 2010 at 8:36 PM, Meadhbh Hamrick <[email-masked]>wrote:

> actually
> being
> JavaScript+WebSockets
> their
> leverage
> isn't
> handed
> page
> into
> And

---

From: Meadhbh Hamrick <[email-masked]>
Date: Wed, 22 Sep 2010 13:42:34 -0700

the purpose of defining data standards is so that you can communicate
things beween servers and between servers and clients.

the web is not the only place where virtual worlds will be rendered.
so while it is possible to define javascript to interpret messages in
proprietary protiocols, this group is interested in defining the wire
formats that communicate information about virtual worlds.
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [email-masked]

On Wed, Sep 22, 2010 at 1:32 PM, Cristina Videira Lopes
<[email-masked]> wrote:
>>> code
>>> clients
>>> this
> Exactly. So you don't pick it apart. And that's a decision of whoever wrote
> the web application. It's not anyone's business.
>
>
>
>

---

From: <[email-masked]>
Date: Wed, 22 Sep 2010 16:43:30 -0400

I currently have psychics running on the client.  But why do I even need to
have physics?  That is a VWRAP requirement?

Simulation takes place on the client.

For or nursing virtual space, the virtual world is a standalone space that
everyone gets their unique copy from.  It does allow for observers and we
can sync object and UI events to them.

I feel we are making so many assumptions about the virtual world and how it
is implemented.  I don't really understand why you are asking the question

K.

-----Original Message-----
From: Meadhbh Hamrick [mailto:[email-masked]] 
Sent: Wednesday, September 22, 2010 4:25 PM
To: [email-masked]
Subject: Re: [vwrap] Consensus? What exactly should be in the protocol

where does physics simulation take place?

in the client or on a server somewhere?
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [email-masked]

On Wed, Sep 22, 2010 at 1:19 PM,  <[email-masked]> wrote:
> Why is virtual world not a web app?  My virtual world runs in a browser
and
> can talk to my webserver.
>
> K.
>
> Meadhbh Hamrick
> Sent: Wednesday, September 22, 2010 3:37 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> implementations

---

From: Meadhbh Hamrick <[email-masked]>
Date: Wed, 22 Sep 2010 13:45:39 -0700

um. since when is UDP a "web technology"?

also, the javascript server you have running in your browser, if
you're behind a NATted firewall, doesn't that require you to
manipulate your firewall to route a public port/address to your
browser?

On Wed, Sep 22, 2010 at 1:38 PM,  <[email-masked]> wrote:
> I also have a game server that uses TCP/UDP that runs from my server, to
> handle the object synchronization.  My point is I am using what all are
> considered web technologies.
>
> I was more making the point, why even say it is a web app or not.  As long
> the exposed behavior of my system supports the protocols and formats that
> are needed it can interact with other systems.
>
> And the URL is the web page that the world is hosted on.  And I had 300+
> avatars walking around in this web page.
>
> K.
>
> Sent: Wednesday, September 22, 2010 4:26 PM
> also. how many other people are connected to your javascript virtual
> region simulator running in your browser?
>
> what URL do you give them to connect to it?
>
> --

---

From: <[email-masked]>
Date: Wed, 22 Sep 2010 16:38:51 -0400

K.

-----Original Message-----
From: Meadhbh Hamrick [mailto:[email-masked]] 
Sent: Wednesday, September 22, 2010 4:26 PM
To: [email-masked]
Subject: Re: [vwrap] Consensus? What exactly should be in the protocol

and

---

From: Meadhbh Hamrick <[email-masked]>
Date: Wed, 22 Sep 2010 13:46:32 -0700

okay. how many people are in your virtual world?

---

From: Dan Olivares <[email-masked]>
Date: Wed, 22 Sep 2010 16:52:49 -0400

I thought the JavaScript portion of this discussion was out of scope.

A client is a client whether it's implemented in JavaScript in a web browser
or if it's implemented as a native application running on a machine.   A
browser+javascript based client isn't more relevant then any other client in
technical terms.

A server can serve a javascript application that then makes use of what we
decide here.
It isn't necessary to assume that it always will be a web browser +
javascript application to produce an effective standard.

Regards

Dan

On Wed, Sep 22, 2010 at 4:45 PM, Meadhbh Hamrick <[email-masked]>wrote:

> Of

---

From: Meadhbh Hamrick <[email-masked]>
Date: Wed, 22 Sep 2010 13:54:59 -0700

kevin mentioned he had a javascript based virtual world simulator that
ran in a browser.

i'm surprised it can support multiple users.

---

From: Morgaine <[email-masked]>
Date: Wed, 22 Sep 2010 22:11:22 +0100

There's a general misapprehension about size and complexity in the core
protocol.  All it's meant to be doing is gluing together services, so if
it's "boiling the ocean" then someone has designed it wrong.  The complexity
is meant to be in the services!  If the services are being hardwired into
the core protocol then it's certainly not extensible, so that prototype has
failed.  Rewrite it, iterating through services supplied on a list.

On a broader note, I'm going to ignore remarks about "boiling the ocean",
because the phrase has been used repeatedly in this group's past as a way of
simply dismissing other people's suggestions.  That doesn't work.  If there
is a technical problem with a suggestion, describe and discuss the technical
problem.  Warming water is not in scope.

Morgaine.

---

From: <[email-masked]>
Date: Wed, 22 Sep 2010 17:24:51 -0400

I never used the word javascript.  Why are you assuming web based
application needs to use javascript?

-----Original Message-----
From: Meadhbh Hamrick [mailto:[email-masked]] 
Sent: Wednesday, September 22, 2010 4:55 PM
To: Dan Olivares
Cc: [email-masked]; [email-masked]
Subject: Re: [vwrap] Consensus? What exactly should be in the protocol

On Wed, Sep 22, 2010 at 1:52 PM, Dan Olivares <[email-masked]> wrote:
>> >>> that are all equally accepted by the web browser, we are still to
cope
>> >> with

---

From: Dan Olivares <[email-masked]>
Date: Wed, 22 Sep 2010 17:33:26 -0400

I wasn't actually responding to you specifically kevin.   I was just stating
that a javascript client is a client in terms of the definitions that are
established.   I mentioned that because there was some mention of JavaScript
by Ms Cristina Videira Lopes.

Regards

Dan

On Wed, Sep 22, 2010 at 5:24 PM, <[email-masked]> wrote:

> >> >>>> a

---

From: Meadhbh Hamrick <[email-masked]>
Date: Wed, 22 Sep 2010 14:36:46 -0700

because that's what you find in web browsers: HTML rendering,
Javascript and i you're lucky canvas support, SVG and increasingly
WebGL.
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [email-masked]

---

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

> i honestly don't know where morgaine go the idea we weren't going to work

I've looked through my various postings and I can't see what that's in
reference to at all.  But speaking generally ...

It sounds to me like you're confusing the *VWRAP protocol* with *VWRAP
services* here.  They're very distinct!

The VWRAP protocol itself (or what I've been calling the "*core protocol*")
is just a service orchestrator, and it certainly shouldn't know anything
about the nitty gritty of rezzing avatars nor making their assets available
--- we have services in our model for handling such specific tasks with high
scalability and with the ability to evolve.  If the core protocol had the
details of avatar rezzing built it, it would very rapidly become obsolete.
We're factoring out low level tasks into replaceable services in order to
avoid that.  It's part of our protocol extensibility.

It doesn't even make sense to ask whether the whole ensemble of VWRAP core
protocol and all services would handle avatar rezzing.  With all the
services included, it's meant to provide a complete world system of the kind
we run today in SL or OpenSimulator, not a partial one!  How could it not
implement something as basic as avatar rezzing?

While I'm not sure where the question actually arose, if I said that avatar
rezzing was not done then we must have been talking about the VWRAP
*core*protocol, since no other interpretation really makes sense.
(But please
show me where I said this so I can confirm.)  And it's true.  The core
protocol should deal only with service orchestration.

We haven't really developed a naming system for our services, so our
references to them have always been somewhat sloppy, and what you mention
above seems to have been an artifact of this.

We have this really nice concept of a VWRAP protocol (I seem to be the only
one calling it the VWRAP "*core protocol*") plus a constellation of services
that it orchestrates.  This gives us great decoupling, easy evolution,
scalability because the services are web services and also because the
number of services is itself variable, and it offers great flexibility in
deployment patterns through service choices and service location choices.
And then after all that nice decomposition, apparently we call every part of
it "VWRAP" without the ability to distinguish the core protocol from the
services.  That's not very useful.

I suggest we call our main protocol VWRAP.Core, and our services
VWRAP.Inventory, VWRAP.Asset, VWRAP.Region, VWRAP.Teleport, VWRAP.Avatar,
and so on to cover all the services required by a world.  (And our documents
should be laid out to match.)  VWRAP.Core would be the core protocol that
engages all the others as optional services.  Then we could cleanly state
that VWRAP.Core just glues services together, and that when a teleport is
requested it engages VWRAP.Region, VWRAP.Teleport, VWRAP.Avatar, and any
other services needed for completion of a teleport.

Currently our descriptions are not very self-explanatory and seem to be
causing ambiguity because we have no official means of naming the various
parts.

Morgaine.

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