Re: [ogpx] VWRAP still alive?

[Morgaine <[e-mail]>]

The preceding reply escaped from Gmail while only half done, please ignore
or delete.  The intended reply will follow.

Morgaine.



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

On Sun, Nov 29, 2009 at 4:30 PM, Morgaine <[e-mail]>wrote;wrote:

> 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:
>
>> 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
>>
>
>