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

[Meadhbh Hamrick <[e-mail]>]

this is part of the reason we wanted to break stuff up in to different
documents. say all the docs we propose become RFCs, deployers could choose
to implement some, but not all of the RFCs. eventually if we want VWRAP to
advance to the "real" standard stage, you have to demonstrate at least two
genetically distinct implementations.

so as we move forward, if it turns out that we lose interest in half the
specs, they can wither and die without affecting the others. or at least
that was the idea.

and i think barry and josh can comment on this a little more
authoritatively, but my understanding is that if, as a group, we decide to
add a new document to the charter, it's not _that_ difficult to do. removing
documents is a little harder, but not completely impossible.

-cheers
-meadhbh
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [e-mail]


On Wed, Apr 28, 2010 at 5:59 PM, John Hurliman <[e-mail]>wrote;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
>