Re: [vwrap] Comments on http://tools.ietf.org/html/draft-ietf-vwrap-intro-00

[Cristina Videira Lopes <[e-mail]>]

Virtual world interoperability should scope itself to the following:
(1) If you want your users to visit other virtual worlds, then you 
should support "these" protocols
(2) If you want to accept visitors from other virtual worlds, then you 
should support "these other" protocols

That's it. Everything else should be off limits for VW interoperability.

This is relatively easy to do under the condition of one single client. 
It's extremely difficult (read impossible) when there are many -- for 
that, we'd be better off using the LESS model/protocol suggested by Jon 
Watte, i.e. we don't really send the user agent there, we send a proxy 
of the the user agent.

Not all clients are the same, though. There are fat clients like LL's, 
Forterra's, WoW, etc. and then there are thin ones like the Web browser. 
The Web browser happens to have the wonderful property of including an 
interpreter for a dynamic programming language, so it can do things like 
taking in entire viewer programs dynamically as it makes its first 
request to a VW server-side. With this, scene server / viewer protocols 
become a non-issue: the client simply gets a new viewer program as it 
moves from world to world.

Interoperability under the web-browser viewer model is as simple as 
putting in place a single sign-on authentication protocol (not the same 
as openid), and then, additionally, agreeing on data formats for asset 
representation and asset exchange protocols if the worlds wish to engage 
in asset exchanges. And that's what the Hypergrid 1.5 does.

(FYI, I'm just finishing an implementation of HG1.5 for non-virtual 
world web-based systems.)

But, again, I'm not sure that this group, as chartered, is about virtual 
world interoperability. It seems that it's about communication and trust 
issues in a generic distributed service composition model, independent 
of what the services do, which seems really ambitious! And that's where 
I got all confused. On the one hand, we should not derail what has been 
chartered long ago and, supposedly, consented by the entire group; on 
the other, the charter and that intro document suggest that what's going 
to come out of here is not going to have a strong impact in the practice 
of virtual worlds, because it makes unacceptable interferences on the 
server side.

But I  suggest that we try to incrementally improve the existing 
documents, rather than making a sharp left turn.

David W Levine wrote:
>
> The "One avatar in place" restriction touches remarkably little of the 
> working group's remit. I've argued against it, as it's very much a 
> policy proscription not a protocol design issue. Allowing an agent to 
> project multiple avatars into the greater grid adds very little 
> complexity to the collective protocols, and frankly should be a policy 
> choice of the people deploying the service(s).
>
> If you look at the deploymet patterns document from last spring, 
> you'll see that I strongly encourage thinking of VWRAP as a set of 
> services which can be composed to allow many different deployments. In 
> general, the matter of how the services compose at run time, and which 
> policies are applied at run time, should be accounted for as "Do we 
> permit people to make choices" and "MUST we constrain this choice" 
> When we hit "We must constrain this choice" I think we need to offer 
> very strong justifications. (e.g. "If you don't constrain this, you 
> can't really do interpo."
>
> - David
> ~ Zha
>
>
> Inactive hide details for Cristina Videira Lopes ---09/19/2010 
> 01:05:21 PM---In defense of Meadhbh's position, the charter for 
> Cristina Videira Lopes ---09/19/2010 01:05:21 PM---In defense of 
> Meadhbh's position, the charter for VWRAP does, indeed, support what 
> she is saying, d
>
>
> From: 	
> Cristina Videira Lopes <[e-mail]>
>
> To: 	
> "[e-mail]" <[e-mail]>
>
> Date: 	
> 09/19/2010 01:05 PM
>
> Subject: 	
> Re: [vwrap] Comments on 
> http://tools.ietf.org/html/draft-ietf-vwrap-intro-00
>
> Sent by: 	
> [e-mail]
>
> ------------------------------------------------------------------------
>
>
>
> In defense of Meadhbh's position, the charter for VWRAP does, indeed, 
> support what she is saying, down to "a collaborative 3-dimensional 
> virtual environment" and "An avatar exists in at most one location 
> within a shared virtual space.":_
> __http://tools.ietf.org/wg/vwrap/charters_
>
> Charters are the binding goals of working groups, I think. Hence my 
> review stated as "this does not reflect the goals of the OpenSimulator 
> project, and I don't know what to make of it." I was truly puzzled 
> when I read the intro doc.
>
> But now that I thought more about, I think there's a way out of this 
> puzzlement. In my spectrum of requirements for clients, there is a 
> point in there where one assumes the existence of one, and the same, 
> client. Let's make this group focus on that. We can assume, roughly, 
> the Linden Lab client, or some variation of it, since I think that 
> this group does not have representatives from other radically 
> different viewers. The thing that needs to be revised, I think, is the 
> very strong interference that the intro document makes wrt the 
> internals of each virtual world server-side system -- that is never 
> going to fly, not even among operators of virtual worlds of the same 
> species! We are already seeing that in the small ecosystem of 
> OpenSimulator-based virtual worlds.
>
> ---
> Personally, I'm becoming more and more interested in web-browser-based 
> viewers, or something like them. I.e. viewers that are simply shells 
> that receive, essentially, a lambda implementing the viewer itself. 
> That's the way to go. But that doesn't exist yet, not in production at 
> least.
>
> Fleep Tuque wrote:
>
>             Hi all,
>
>             I'm sure I need to go back through and re-read some of
>             these documents to find definitions, but I must be missing
>             something entirely. I've been lurking on this list for
>             some months and the statement that "VWRAP is not now, nor
>             has it ever been a protocol to enable
>             interoperability BETWEEN virtual worlds" took me
>             completely by surprise. I've been under the impression
>             that was the entire point of this effort!
>
>             The OpenSim model described by Cristina, and the concerns
>             raised by the message at the start of this thread, pretty
>             closely reflect my views and concerns. A consortia of
>             universities is developing in which each university will
>             operate its own "world" - using their own access and
>             authentication schemes, internal system architecture, etc.
>             - but allow our researchers/students to be able to connect
>             and go to the worlds of other participating members to
>             collaborate on research projects. We need protocols to
>             help establish the ground rules for that connection, and
>             what the baseline requirements are for our "world" systems
>             to be able to communicate with one another, but ideally to
>             be as minimally intrusive/restrictive as possible.
>
>             Part of the interest in this experiment is similar to the
>             "laboratories of democracy" model in which each
>             institution CAN and SHOULD do its own thing internally so
>             we can see what sorts of best practices and innovation in
>             internal system design emerges. (In fact we have little
>             choice, since each institution is bound by different laws
>             and policies governing things like authentication and
>             student data.) In our use case, this is not a "tourist"
>             model OR a "walled garden" model - it's both! Each
>             institution intends/needs to have areas of their "world"
>             that are off limits to other institutions, and some areas
>             that are accessible to members of the consortia. Figuring
>             out which bits we need to pass back and forth to make this
>             work is, I thought, what VWRAP would be addressing.
>
>
>             I will go back through and re-read the source documents
>             with Meadhbh's comments in mind, but I wanted to chime in
>             and say Cristina's concerns and perspective pretty closely
>             represent my interests as well. And I think it's a mistake
>             to frame the conversation as a "tourist" model vs a
>             "walled garden" model even hypothetically, since as far as
>             I can tell, we are much more likely to see hybrids of the
>             two than any pure implementation of either in the
>             ecosystem of worlds that Cristina rightly points out are
>             already developing. In any case, a protocol that assumes
>             only one world seems on its face of very little value to
>             _anyone_ if the point is not to have interoperability
>             between worlds using the protocol!
>
>
>             Confused and befuddled,
>
>             - Chris/Fleep
>
>
>             Chris M. Collins (SL: Fleep Tuque)
>             Project Manager, UC Second Life
>             Second Life Ambassador, Ohio Learning Network
>             UCit Instructional & Research Computing
>             University of Cincinnati
>             406E Zimmer Hall
>             PO Box 210088
>             Cincinnati, OH 45221-0088
>             [phone]_
>             [e-mail]_ <mailto:[e-mail]>
>
>             UC Second Life: _http://homepages.uc.edu/secondlife_
>             OLN Second Life:
>             _http://www.oln.org/emerging_technologies/emtech.php_
>
>
>
>
>
>
>
>
>
>             ------------------------------------------------------------------------
>
>             _______________________________________________
>             vwrap mailing list
>             [e-mail]_ <mailto:[e-mail]>
>             _https://www.ietf.org/mailman/listinfo/vwrap_
>               
>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>
>