Re: [ogpx] VWRAP still alive?

["Infinity Linden (Meadhbh Hamrick)" <[e-mail]>]

what issues do you wish to discuss, specifically, morgaine?

--
  infinity linden (aka meadhbh hamrick)  *  it's pronounced "maeve"
        http://wiki.secondlife.com/wiki/User:Infinity_Linden


On Sun, Nov 29, 2009 at 09:13, Morgaine <[e-mail]>wrote;wrote:

> Might I suggest that, instead of working on several documents behind closed
> doors, that 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 in a linear discussion.  The documents are not independent of
> each other, so writing a number 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 requires a very large number of changes as a result of
> our removal of "one world" wording from the charter, for consistency and
> clarity and to avoid the question of "Which world?" at any given time.
>
> Our protocol is very different now from the early days of OGP.  In effect,
> it treats every region domain (and potentially every region) as a separate
> world, since they can each have local policies, separate asset services, and
> so on --- in other words, there is no longer any single world, which is why
> we found an easy basis for agreement in the charter.  The documents need to
> reflect that, starting from the Intro.
>
>
> On Sun, Nov 29, 2009 at 2:31 PM, Meadhbh Hamrick <
> [e-mail]> wrote:
>
> 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.
>
>
> The right place for coordinating this is VWRAP, so that decisions made in
> the name of "coordination" obtain early input from the VWRAP contributors.
> That's what we're here for.
>
> In particular, we have already been discussing the operation of multiple
> asset services right here with Joshua, so how this might work in conjunction
> with Cable Beach is a matter of much interest to us.  There are bound to be
> numerous alternative approaches, so I recommend that they be discussed
> openly here with a lot of eyeballs on the problem, while ideas are still
> fluid.
>
>
> Morgaine.
>
>
> ==========================================
>
> 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
>>
>
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>