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

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

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