Re: [vwrap] End point "behavior" (was: one question)

[Meadhbh Hamrick <[e-mail]>]

oh. upon re-reading this, maybe it would be good for me to reiterate
some of the motivations for LLSD/LLIDL (later DSD).

a lot of people think that LLSD is an XML DTD for communicating random
bits to and from Second Life. it's understandable to think that since
that's the most common use we see in the wild. and.. the LLSD drafts
have been a little fuzzy on the motivation behind LLSD. (something i'm
fixing in the next rev.)

LLSD was originally thought of as an "abstract type system." that
means it's purely hypothetical. we used it inside linden to define
data structures in a programming language independent way. it was used
mostly to communicate ideas and data structures between engineers when
we were developing services.

because it was "abstract" it was not supposed to be directly
implemented. rather, in each programming language we used, we would
create a mapping between abstract types in LLSD and "reified" types in
an actual programming language. if you search, you can find python and
c++ implementations in the source code linden open sourced. (and
possibly a PHP implementation, can't remember.)

so, we liked to make service interfaces that were defined using LLSD
because that way we don't accidentally impose type behavior of one
language (C++) on another (python).

when it was time to communicate with these services, we had to
serialize / marshal data structures defined using LLSD into an octet
stream that could go over the network. an early implementation of this
was the "annotation format" which looked remarkably like JSON. then
the people who advocated the annotation format were sacked and we got
some more people who really liked XML. that's where the XML
serialization came from.

some of our web developers and many external peeps commented that the
annotation format was nice 'cause it was so much like JSON and they
really liked JSON. so someone snuck some code into the tree that
serialized/deserialized LLSD into JSON. there was a wailing and
gnashing of teeth because at the time we were drinking too much good
scotch to realize we had better things to worry about.

and somewhere in there someone decided that XML was for "high level
language dweebs" and added the binary serialization. (this actually
isn't really true, but its the story we invented because the truth was
much more boring.)

but the idea here was we felt there were some situations that called
for a binary serialization, some that called for a json serialization
and some that called for an XML serialization. at one point i think
all of second life's external LLSD based interfaces only accepted XML,
but the plan was always to eventually getting around to making them
serialization independent whenever we opened up an OGP compliant grid.

XML vs. JSON vs. Binary was still a minor subject of debate when i was
at the lab, but i think everyone was on board with the idea that if we
had a real-live 'open' interface, we would "do the right thing" and
support all serializations, OR, publish a big note somewhere that said
"if you deal with us, you give us XML."

when we specified LLSD and LLIDL, our believe was that peeps who
exposed LLSD/LLIDL based services would, on an endpoint by endpoint
basis, decide which serialization and transport (HTTP, HTTPS, XMPP or
websockets) was the best choice for their application. that's the
basis, i believe, of mark lentczner's desire to not define a content
negotiation strategy since it might limit the service provider's
freedom in deciding it would only support a single transport or
serialization.

my experience in implementing OGP on the vaak test grid was that our
partners were actually very interested in content negotiation for
LLSD/LLIDL messages over HTTP(S) at least.

so... that's going to show up in the next rev of the type system draft
i'm writing.

so wrapping this thread up and going back to Diva's use case... the
current understanding of VWRAP is that there will be RESTful resources
at the end of HTTP(S) (and possibly XMPP) endpoints. the interface for
these resources will be defined using something like LLSD or DSD (DSD
is the next generation of LLSD. it's a few minor changes and it
removes the "LL" 'cause i wanted a MIME type that was distinct from
LLSD's.) the content of messages to and from these endpoints would be
serialized using the XML, JSON or Binary serialization schemes (aka
transport syntaxes.)

if your JavaScript app is talking to a service that it knows only
supports one of these serialization schemes, then there's no need for
it to support the others. if the server you're talking to only accepts
requests from clients that only make requests in specific schemes,
then there's no need for it to support the others.

but in the real world, we're probably going to see a lot of people use
BOTH JSON and XML. i'm guessing Binary will be more likely to be seen
between hosts in tightly coupled clusters of servers. but heck, i
could be wrong.

so the safe thing to do is for clients to send requests using
serialization schemes they like to generate and ask for responses in
serialization schemes they like to parse. server coders should suck it
up and cope with the fact that it's a diverse world out there and
arguing about XML vs. JSON vs. Binary encoding is just not productive.

or not. because... in this protocol, we specify mechanism, not policy.

-cheers
-meadhbh

p.s. - but if you're in control of both the server and client, then
yeah, just pick whichever serialization scheme you want to use.
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [e-mail]



On Thu, Sep 23, 2010 at 9:38 AM, Boroondas Gupte
<[e-mail]> wrote:
> I'm not up to date with everything here, so I hope I don't get it completely
> wrong, but here's my take:
>
> On 09/23/2010 05:20 PM, Cristina Videira Lopes wrote:
>
> In other words, if my viewer is in JavaScript, I have to make the JavaScript
> program do things in specific ways, and not others, in order to be able to
> interoperate in VWRAP?
>
> Only regarding what they send and receive over the wire when communicating
> with VWRAP services, I think. The web analog would be that to talk to a web
> server, you have to speak and understand HTTP. Depending on what server it
> is and what you'd like to do with it, there might be additional
> requirements, e.g. WebDAV (just an arbitrary example out of many). What you
> do within the bounds of these protocols and what other processing you do
> (including interfacing non-HTTP resources) is completely up to you.
>
> Likewise, to talk to a VRAP service, you'll have to speak and understand
> VWRAP.core and, depending on the kind of service and what you want from it,
> the relevant VWRAP.<insert service type here> protocols. What you do within
> the bounds of these protocols and what other processing you do (maybe
> interfacing non-VWRAP resources) is again up to you.
>
> So the "behavior" of the end point only matters in a black-box way: in what
> can be seen from the VWRAP services. Whatever happens inside (or at the
> non-VWRAP sides of the box) is out-of-scope for a communication protocol.
>
> Cheers,
> Boroondas
>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>
>