Re: [vwrap] Some thoughts on Josh's Linden Lab Legacy Protocol discussion

[David W Levine <[e-mail]>]

Its interesting.  I took Josh's presentation as part of an attempt to look 
at how we
avoid having to specify a ton of stuff when we get to the next round of 
effort, and
very much an attempt to stir some thought. In particular, Josh's proposed 
approach
is very much an effort to keep VWRAP *out* of the business of specifying 
stuff
it doesn't need to specify. 

That said at the "Lets talk about how we might approach problems" level, 
it raised some
interesting questions. Questions I think need some love at the "Does this 
provide a framework
which would let us totally avoid a TON of work in the mainline of the 
workgroup" level. 

The WHOLE point of Josh's proposal and my comments on it is to see if we 
can define
a simple model so that implementers of virtual space services (regions) 
can expose
proprietary extensions in a way which cues the consumer, and gets the 
protocol out of the way. 

I think its not only enough for the group to define the basics, but the 
only way forward. But, that
actually means looking at patterns like "how do I associate my private 
service with
part of the scene I am serving"  The example I gave was explicitly 
described as "so how might
this work" not "We should specify this." 

I think we can start to work out how regions ought to work in parallel 
with updating the base
getting teleport published and merging in the content we've all agreed 
needs merging. The
presentation Josh produced on the legacy protocols is at a high level of 
lets start
thinking about this, as was my response. The ideal out come of that would 
be a
"Yes, this could work"or "Oh, no, it misses these three things, lets see 
how that would work"
as input into describing a very concrete, small set of building blocks 
which would allow
regions to standup proprietary services with web style user interfaces 
hosted by those
services (Nicely requiring zero work from VWRAP) and possibly, also 
showing how
to permit API style services to follow the same path. 

- David
~ Zha



Meadhbh Hamrick <[e-mail]> wrote on 04/28/2010 08:37:25 PM:

> [image removed] 
> 
> Re: [vwrap] Some thoughts on Josh's Linden Lab Legacy Protocol 
discussion
> 
> Meadhbh Hamrick 
> 
> to:
> 
> David W Levine
> 
> 04/28/2010 08:42 PM
> 
> Cc:
> 
> vwrap
> 
> so i feel your pain, david.
> 
> but i want to ask, must the protocol specify ALL possible 
> interfaces? isn't it possible for the VWRAP suite of protocols to 
> specify a set of interfaces and resources for a bare minimum and 
> leave the rest to implementers?
> 
> in other words... i think we can get some radical agreement that 
> authentication and teleportation and so forth are important to all 
> virtual worlds. but we might have some argument that game script and
> land ownership interfaces are universally important.
> 
> maybe it's enough in this working group to define the basics and 
> have other features be proprietary extensions?
> 
> this is one of the features of the OMG process i liked; people could
> extend "CORBA" all they wanted, but if they wanted their extensions 
> to be part of the spec, they had to spend a few days in hotel bars 
> lobbying other members to not object when it's discussed in the 
> orbos meetings.
> 
> in other words... would it kill us if we moved forward with what we 
> seem to have agreed to in the chartering process, let people try 
> several different solutions for annotation of objects in the virtual
> world, write a bunch of competing drafts, then retire to the hotel 
> bar for a few days and come out with an agreement for how we handle 
> different "extensions"?
> 
> -cheers
> -meadhbh
> --
> meadhbh hamrick * it's pronounced "maeve"
> @OhMeadhbh * http://meadhbh.org/ * [e-mail]
> 

> On Tue, Apr 27, 2010 at 2:41 PM, David W Levine <[e-mail]> wrote:
> 
> As always, food for thought, probably partly baked. 
> 
> Josh Linden's presentation on the Linden Legacy Protocol 
> raises the possibility that a substantial number of 
> operations currently managed by the Linden Labs client be 
> viewed as "out of scope" for VWRAP and exposed as "there is 
> a URI/URL which provides access to a service to perform this 
> task." 
> 
> Thus rather than including a set of LLIDL messages which define 
> how to set parcel permissions, you would associate a "Here is a 
> URI to invoke to get to a UI about this parcel" 
> 
> I would argue this solves roughly 1/3 of the problem. It makes it very 
> easy for a deployed to provide a customer user interface, and it nicely 
> reduces the amount of work needed to describe a useful protocol. I also 
> said 1/3 because I think it misses two things. First, it begs the 
> question(s) "What cues are needed to let the client know where things 
> happen" and second, it misses the need to expose the attributes these 
> interfaces would manage in a programmatic fashion. 
> 
> Effectively, the first problem is one of asking "How do we overlay the 
> scene graph with UI cues." The more I think about it, the more I like 
> the idea of solving this problem elegantly. In particular, the obvious 
> design "This portion of the scenegraph or this broad area of virtual 
> space" has "This URI" to invoke for more information seems pretty 
> straightforward. How to cue things like "parcel boundaries" and "Has 
this 
> property" is a little less obvious, but a good solution would be well 
> worth having. Notice that this also allows some potentially elegant 
> integration points. One could expose custom web page UIs as associated 
> with Vendors, Buildings, portions of the ground, or any part of the 
> scenegraph. 
> 
> The second problem is also one worth solving, tho its more difficult. 
> I think it falls into two or three parts. The easy bit, is again, the 
> "cue" issue. In short, how does one find out that there *is* structured 
> data or an API associated with some portion of virtual space. At one 
> level, the temptation is to say the web solves this already, and blend 
> it in with an overall scheme for associating URIs with each bit of 
> virtual space or virtual item. I'm not sure this is sufficient, but I 
> think it serves as a nice starting point. 
> 
> I think a small worked example would be helpful. This is intended to be 
> fairly accurate, but clearly not more than a thought experiment. 
> 
> Posit a virtual space which wishes to expose an administrative 
> interface which permits visitors with proper permission to change 
> several parameters of the physics engine. The current model of things 
> would require a cap and a custom bit of user interface, or user 
> interface exposed via some "in world" hook, such as a prim exposing a 
> web page, or a web page entirely disjoint from the inworld experience. 
> 
> Instead, we would provide a way for the region to advertize the 
> existence of the service to the client. I am, for example, imagining 
> either a capability exposed by the region, or a public URI/URL exposed 
by 
> the client. (Whether the approach is fully web centric, or blended in 
> with VWRAP style of capability access is clearly something worthy of 
> discussion)   
> 
> The client, on arrival to the region, fetches the URI, using content 
> negotiation and gets back a "cue" to display to the user that a service 
> is available. (Content negotiation let web based internationalization 
> and such simply happens) The cue is presented to the user as the client 
> sees fit, and if it is invoked, an associated URI launches the 
> user interface web service, which can be pre-fed with context, based 
> on the user. 
> 
> Now, this is doubly inappropriate for a programmatic approach. We 
neither 
> want to make programs screen scrape for content cues, nor do we want to 
> present them with a nice pretty user interface to manipulate. Thus, 
> a structured data path would be desirable. More on thinking about how 
> regions and scenegraph can expose APIs for performing tasks in a future 
post 
> 
> - David 
> ~ Zha 
> 
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap