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

["Hurliman, John" <[e-mail]>]

> -----Original Message-----
> From: Dzonatas Sol [mailto:[e-mail]]
> Sent: Wednesday, April 28, 2010 4:07 PM
> To: David W Levine
> Cc: Hurliman, John; [e-mail]
> Subject: Re: [vwrap] Some thoughts on Josh's Linden Lab Legacy 
> Protocol discussion
> 
> David W Levine wrote:
>> 
>> As I said. Very much partly baked thinking at the moment, ripe for
>> discussion.
>> 
>> - David
>> ~ Zha
>> 
> 
> I looked around for a dictionary of resources for VWRAP, and it looks
> like there isn't a specific set given as the time of the e-mail. I
> read over the VWRAP docs and seen the pattern to follow. I heard there
> are some implementations, yet those implementations haven't really
> exposed a given set beyond the sources that already reveal the older
> OGPX implementation.
> 
> I looked for the VWRAP resource dictionary in order to align SNOW-375
> resources where ever they overlap. So far, SNOW-375 has these:
> https://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources
> 
> There is more in SNOW-375 for full duplex, but that set represents
> some of the common client/server requests.
> 
> If there is a dictionary that has already been negotiated that doesn't
> assume the client is a single end-point, I would like to know of this
> so we can work on this together.
> 
> As you can see from this pic, I do speak of SNOW-375 as a working
> example: http://twitpic.com/1gl71s
> 
> Notice the viewer/render/scenegraph is one window and the rest of the
> UI is each in their own window. These are separate programs, so there
> is more than one end-point on the client-side.
> 
> 

No, there is no dictionary of resources defined in the VWRAP spec so far. Although I haven't seen a roadmap for VWRAP yet, my current understanding is something like this:

1. Agree on common low level protocols
 a. Common types
 b. Common serializations
 c. Common transports
2. Define a system for requesting and consuming resources
 a. Defining resource providers and consumers
 b. Authorization/authentication
 c. Service and content negotiation
3. Defining service endpoints
 a. Categorize each set of service requirements, determine what needs API-level standardization and what is treated as an "opaque" endpoint
 b. Standardize one of the special service requirements
 c. Repeat b. until someone declares the current effort "done"
 d. Repeat b. as unofficial extensions that aim to influence VWRAP2


Where we don’t start to see a meaningful list of RFC-referenced or commonly used service endpoints and the draft protocols for those until around 3b, and we're more or less finishing 1c and starting discussion on 2a right now (with some open ended discussion looking forward thrown in). This isn't an official roadmap or inside knowledge, just my personal observation from the I-Ds, IETF gatherings, virtual meetings, and mailing list discussions. If anyone has a deeper or more clear insight into what we're doing please correct my roadmap.

John