Re: [ogpx] VWRAP still alive?

[Meadhbh Hamrick <[e-mail]>]

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