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

[Bill Windwalker <[e-mail]>]

I am all for the Legacy Protocol as long as the Legacy Protocol will not hold linden lab back for it starting to look like there is a great need for more then one type of Viewer made by Linden Lab.
For holding on to buggy whip in side a race car is not needed and thats how some of Legacy software works.
First what will it cost later on ?
will it hold the company back?
how many people wil use it?
are there not other steps to be taken ?




________________________________
From: Morgaine <[e-mail]>
To: [e-mail]
Sent: Thu, April 29, 2010 1:45:17 PM
Subject: Re: [vwrap] Some thoughts on Josh's Linden Lab Legacy Protocol discussion

I suspect that everyone would agree that we should find the smallest set of protocol requirements that covers the primary use cases effectively.  There is of course a proviso implied there --- less common use cases must still be possible. Our protocol framework must be flexible and extensible enough to allow that.

Ever since David gave us his document on the deployment patterns that are possible when services are decoupled, I think we have been charting a steady course through fairly calm waters, because we haven't needed to pick and choose deployments.  Instead, our VWRAP protocol need only provide the glue to link decoupled services together, thus allowing a wide range of deployments to be chosen by individual VW service providers.

That view provides a structural target for us:  to make the VWRAP protocol an effective glue for services, in the same sense as the Unix shell is an effective glue for binding together Unix programs into multi-part applications.  In our case, the protocol will bind together services to create a system of interoperating worlds.

What we should do therefore is to enumerate the primary use cases consistent with our agreed charter, and to find the smallest amount of protocol glue that satisfies those requirements (and the charter), without cutting off other use cases.

Different people will of course champion different use cases in accordance with their interests, which is perfectly fine and to be expected.  The protocol needs to cover those particular use cases well.  If our protocol is not flexible enough to cover even the WG's members' core deployments then it certainly won't be flexible enough to allow for less common use cases, and we will have failed.

The core deployment patterns of most interest to me are those that allow tourism among multiple virtual worlds (the major use case for open worlds interop), so of course I will continue to champion those use cases.  At the other end of the spectrum we have "walled garden" deployments, and others in between.  As long as we ensure that services are fully decoupled, and as long as singletons are avoided (eg. for asset storage), we should not have a major problem in achieving this spectrum of goals within a very concise protocol.

That said, the above is not enough.

I agree with David entirely that a fundamental part of the interop problem concerns associating components of the perceived VW experience with services, programmatically.  It is not enough merely to specify services.  Clients have to be able to combine them programmatically to create the composite 3D audio/visual/textual mashup.  If we don't provide a way of doing this then we have failed to deliver a protocol for interop.

So let's find our core requirements based on our core use cases, and let's find a small but powerful mechanism that allows services to be combined in creating the VW mashup for interop, and we will have succeeded.


Morgaine.






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


On Thu, Apr 29, 2010 at 1:59 AM, John Hurliman <[e-mail]> wrote:

+1 to moving forward with a bare minimum set of requirements. The trap I want to avoid is getting rough consensus that there are a ten different areas where we need to standardize communication, but when it comes time to actually doing the standards work it turns out only five of those areas are relevant to the active participants. The other five areas receive a fair dose of idle speculation, but otherwise go nowhere and stall the overall process.
>
>If anyone identifies a specific resource (service endpoint, set of endpoints, suite of bi-directional events, whatever) that they want to see standardized, I would prefer to see it drafted / prototyped / alpha tested before arguing that it should be officially sanctioned by VWRAP.
>
>John 
>
>
>On 4/28/2010 5:37 PM, Meadhbh Hamrick wrote:
>
>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]
>><mailto:[e-mail]> 
>>
>>
>>
>>On Tue, Apr 27, 2010 at 2:41 PM, David W Levine <[e-mail]
>>
>><mailto:[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] <mailto:[e-mail]> 
>>
>>   https://www.ietf.org/mailman/listinfo/vwrap
>>
>>
>>
>
>_______________________________________________
>vwrap mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/vwrap
>