Re: [ogpx] VWRAP still alive?

[Morgaine <[e-mail]>]

Might I suggest that, instead of working on several documents behind closed
doors, that instead those documents be worked on *one at a time* right here
*in the VWRAP list* where that effort belongs?

That was how we managed to arrive at a group charter in a timely fashion, by
focusing on one thing at a time so that the whole group could contribute
meaningfully to a linear discussion.  The documents are not independent of
each other, so writing a pile of them simultaneously just creates inertia in
the process of change and promotes a desire for rubber-stamping, which isn't
going to happen.

The Intro document req



On Sun, Nov 29, 2009 at 2:31 PM, Meadhbh Hamrick
<[e-mail]>wrote;wrote:

> yes, VWRAP _is_ still alive.
>
> we're currently working on three documents: LLSD / LLIDL, Intro and
> Requirements, and Assets
>
> * LLSD / LLIDL
>
> LLIDL was in the middle of getting a well deserved face lift when
> multiple, conflicting changes forced us to return to agreeing on the
> problem definition instead of pushing out a draft. LLIDL / LLSD draft
> development has been being informed by several pairwise / intense
> descussions involving investigation of specific use cases. i hope to
> get a wiki page up describing proposed changes at the end of this
> week.
>
> but essentially what we're looking at is thus:
>
> - peeps didn't grok why LLSD has the "you get the default value when
> you read a map key that's not there" semantics, so i'm integrating the
> "structure and interpretation of LLSD messages" email into the draft
> as motivation for why LLSD is needed. (
> http://www.ietf.org/mail-archive/web/mmox/current/msg00679.html )
>
> - peeps thought the LLIDL syntax was odd, that it didn't look "Cish
> enough." i'm developing a proposal for making LLIDL look more like an
> ALGOL derived language so C/C++/C#/Java programmers can look at it and
> have a more immediate understanding of what it's doing.
>
> - we want to be able to support GETs as well as POSTs when LLSD is
> carried over HTTP(S). this is so we an make use of intermediaries like
> caching squid servers. so we're working on a way to map a resource
> definition to a GET instead of a POST. i know there are some people
> who want to carry LLSD over XMPP, so we're interested in avoiding
> simply saying... "oh... just make this kind of message a GET" since
> that's more of a HTTP(S) specific construction.
>
> - related to the item above, we're looking at ways to encode a request
> as a query string. the idea here being that since some caching
> intermediaries can cache two GET requests with the same URL, including
> the query string, we want to be able to encode the request in the
> query string to take advantage of the caching behavior.
>
> - some people thought that the variant syntax was confusing.
> specifically, the relationship  between a variant record and the
> selector. (the selector is the element _in_ the variant map
> declaration that has a literal value.) in other words, the way the
> LLIDL parser knows that a particular variant is "valid" is that one of
> the members of the map has a specific value. the relationship to the
> variant and the selector was considered "haphazard" by some reviewers.
>
> - explaining the use of "late keys." i.e. - the '$' in some LLIDL
> definitions. the use of the dollar sign ('$') in LLIDL as the key of a
> map declaration indicates that there'll be a number of keys, the
> symbol for each is determined at message send time, not at resource
> definition time.
>
> - fixing things like broken XML DTDs.
>
> - changing the comment character from a semi-colon (';') to a hash mark
> ('#')
>
> * Intro and Goals
>
> There was a lot of commentary on the original "intro and requirements"
> doc in Stockholm, and a trickle of interest since then. There are a
> few minor changes to the draft, and the inclusion of a much better
> glossary. David is writing a section on deployment patterns, and we
> plan to integrate our changes "any day now."
>
> * Assets
>
> The Assets draft is in a much more "complicated" state. We're
> coordinating our efforts with John Hurliman who's the lead developer
> on the Cable Beach project. We hope that what will emerge will be a
> unified protocol for accessing second life resources as cable beach
> resources.
>
> -cheers
> -meadhbh
>
> On Sun, Nov 29, 2009 at 5:42 AM, Vaughn Deluca <[e-mail]>
> wrote:
> > It has gotten terribly silent on the list, and its not hard to see why;
> > without updates of the drafts the discussion floats free and people are
> > bound to loose interest.
> > I  do understand that drafting these types of documents takes time, and
> too
> > much discussion in an early stage sometimes only complicates matters,
> yet, a
> > quick status update and maybe even a working version of the drafts in
> their
> > current form would be nice to keep everybody synchronised...
> > -Vaughn
> > _______________________________________________
> > ogpx mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ogpx
> >
> >
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>