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

[Morgaine <[e-mail]>]

I'm glad to see Dzonatas bring this topic to the fore.

When designing a software system or a protocol in the REST architectural
style, the task of problem analysis is first and foremost concerned with
splitting the problem space into REST resources or nouns.  This is as
central to REST as analyzing a problem into classes and objects is in
Object-Oriented design.

Unless you know what your nouns are, you don't actually have anything
concrete to talk about (in the REST sense).  I've been trying to get a list
of REST nouns out of OGP designers since the beginning of the AWG effort,
and the response has always been that "it's coming shortly".  It is a puzzle
to me why it never materialized.

If in VWRAP we are choosing to stick with REST, then I suggest that we had
better populate our noun-space rather quickly, because a REST-based protocol
is best defined as the messaging that operates a state machine over the
states of its REST nouns.


Morgaine.




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

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

> > -----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
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>