Re: [ogpx] VWRAP still alive?

[Morgaine <[e-mail]>]

On the Intro, a good place to start would be to take the document apart
top-down, get agreement on its scope and on what is NOT to be included
because it belongs in more detailed documents, agree on appropriate
sections, and fill them in --- largely from the old OGP material modified as
appropriate, I hope.  (This is how we made good progress on the charter
too.)   Another possibility is to leave the Intro until last, once we know
all the material that it's meant to introduce in overview --- it may be far
too early now because so much is changing.

On the "coordination with Cable Beach", really that should start with John
giving us some idea here of how he sees Cable Beach and VWRAP dovetailing.
Cable Beach was announced  on the MMOX
list<http://www.ietf.org/mail-archive/web/mmox/current/msg01378.html>ml>,
yet we have been told on many occasions that the material on MMOX is
(by
definition) out of scope of OGPX/VWRAP, so there would seem to be some
confusion about MMOX vs OGPX scopes here if we're "coordinating with CB".

Cable Beach was developed independently by John's team at Intel.  An early
version was incorporated into Opensim, and most recently the realXtend
mailing list has mentioned that Cable Beach is evolving to integrate into
realXtend's new system design with its WebDAV-powered inventories, as
I  reported
here earlier<http://www.ietf.org/mail-archive/web/ogpx/current/msg00391.html>ml>.
 This is all extremely interesting and even
*exciting* in the rapid progress it shows, but it does beg the question of
how progress in VWRAP fits in with everyone else's ongoing evolution.  CB is
not any kind of standard after all, it's Work In Progress, and at a rather
early stage of its design, so dependence on it needs to be explained.

Back in September, John
said<http://www.ietf.org/mail-archive/web/ogpx/current/msg00338.html>"
*I can't personally commit any development effort to VWRAP work at this
time, but I will continue to periodically sync Intel's Cable Beach work with
the VWRAP work and aim for a merging of features in the future*".  That
seemed to suggest that CB would follow VWRAP, but it left a lot unsaid.  We
had not even considered multiple asset services and policy-determining
regions back then.  Is it still on track to follow us?  What exactly is the
dependency between our two projects?

Personally I am very happy to see OGP take on in VWRAP a more embracing
concept of interop than its original narrow one, but this does need a lot of
clarification so that we know exactly what we're doing and why, since our
charter was made a narrow one on purpose.  I welcome the new breadth, but we
need to state what we're doing clearly and openly, and explain our new scope
and dependencies.


Morgaine.




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

On Sun, Nov 29, 2009 at 6:11 PM, Infinity Linden (Meadhbh Hamrick) <
[e-mail]> wrote:

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