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

[Meadhbh Hamrick <[e-mail]>]

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