Subject: [mmox] Proposal for small enhancement in the LLSD draft

From: Catherine Pfeffer <[email-masked]>
Date: Wed, 11 Feb 2009 11:32:23 +0100

Hi all,

I propose to add to the xxSD draft:

 "Agreement on the type of serialization used is not in the scope of this
document"

to show that we've thought about the problem of the negociation of type of
serialization.

Or if there is a preferred serialization, like XML, mention it.
Or if the type of used serialization is hardwired into a given grid, say it.
Or if all grids are supposed to support all types of serialization, say it.

But my feeling is that currently this point is left in the dark.

Sorry in advance if this point is mentioned in the draft and I have missed
it. I tend to read things a bit quickly because of lack of time.

-- 
Catherine Pfeffer

---

From: Morgaine Dinova <[email-masked]>
Date: Wed, 11 Feb 2009 14:44:19 +0000

Catherine, some of the "omissions" you mention actually reflect a desirable
property of specifications:  Separation of Concerns.  Every time that a
document becomes more strongly associated with one problem domain, the less
useful it becomes in others.  If you employ generic formats then you can
employ generic tools instead of having to create your own tools specific to
your domain --- a great benefit.

LLSD is an Abstract Data Type specification, but an ADT is not a protocol so
you would not expect an ADT spec to discuss negotiation of serialization
formats --- that belongs in the negotiation section of a wire protocol
document.  And while Virtual Worlds will make use of specific ADT structures
and map their VW data onto them, the VW is merely a SPECIFIC USER of
structures defined by the ADT, not an exclusive definer of the ADT as that
would be leaking VW concepts into the ADT spec.  (ADTs are "Abstract" by
design and intent for reasons already mentioned.)

In addition, Separation of Concerns is very strongly related to the idea of
Decoupling which is so central to taming software engineering difficulties.
If two documents describe different aspects of a system then you are quite
likely to be able to change one without changing the other, which is much
less likely if they are intertwined.  This benefit of separation doesn't end
with the documents either, but carries over to the corresponding
implementations as well.  Decoupling is A Good Thing.

On the issue of "preferred serialization", this doesn't really hold together
when you look at what it implies.  If a system offers two alternative
serializations then they need to be equivalent in all important respects or
they're not actually alternatives at all.  If they are true alternatives
then this means that the system has implemented both fully, so why then
would the spec express a preference?

Which one is better is entirely dependent on the quality of individual
implementations.  For example, both XML and JSON implementations are
available with a very broad spectrum of performances, and therefore
declaring a preference for JSON as "usually" faster than XML could in
practice be quite wrong.  If you're going to offer multiple serializations
then "ranking" them should not be prejudged.

Morgaine.

On Wed, Feb 11, 2009 at 10:32 AM, Catherine Pfeffer
<[email-masked]>wrote:

> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox
>
>

---

From: Mark Lentczner <[email-masked]>
Date: Wed, 11 Feb 2009 08:47:02 -0800

I agree there is some ambiguity about what is the intent of having  
multiple serializations. I see several possible approaches:

1) We insist that all systems that accept LLSD implement all  
serializations.  This leaves the choice up to the generator of the data.

2) We leave the choice up to the consumer of the data, and declare  
that all requests for LLSD must include some content type negotiation  
mechanism (such as in HTTP), and therefore all generators of LLSD must  
support all serializations.

3) One serialization is chosen to be "mandatory", the rest are optional.

4) No preference or requirement of support is stated.

Working backwards:

I don't support #4, because it doesn't ensure interoperability. It  
means different systems would have to advertise, out of band, what  
forms they accepted and generated.  This strikes me of being like the  
early days of TIFF format, where complaint software would often be  
unable to read each others' files.

Option #3 has the easiest interoperability story.  But, unless there  
are major advantages to the non-required serializations, there will be  
little support for them. After all, once you've done the one required  
format, why do the others? We only have internal experience data to  
compare two of the formats, and not enough inter-system experience to  
know what would be best here. If experience shows that there is little  
practical difference between supporting the different serializations,  
then one might question why define alternatives.

If we thought there would be many many more consumers of LLSD vs.  
producers, then #2 would make sense. However, it does place a burden  
of content negotiation on any protocol or process that transmits  
serialized LLSD. On the face of it, I think the premise here is false:  
I believe that all sub-systems in an OGP network will produce and  
consume LLSD with equal frequency. Another argument in favor of #2 is  
that parsing tends to be the more expensive operation in LLSD  
transport, and different implementations will favor different parsing  
solutions, often because they match the semantics and/or type systems  
of the implementation language.

If there was a substantial expense in serializing LLSD, then #1 would  
allow implementations to choose what suits them best. However, this is  
also not borne out by experience: Generating these different  
serializations takes about the same amount of work. In fact they can  
all easily be generated by the same code using a common base class and  
having subclasses supply strings for structure and a few overridden  
routines for string escaping and such.

My sense is that we will settle on either #3 or #2. Until then, I  
think we are all operating under approach #5:

5) Support for all serializations is mandatory.

	- Mark

Mark Lentczner
Sr. Systems Architect
Technology Integration
Linden Lab

[email-masked]

Zero Linden
[email-masked]

---

From: Morgaine Dinova <[email-masked]>
Date: Thu, 12 Feb 2009 04:08:00 +0000

The IETF's "Robustness Principle" suggests a good approach to use in this
area:  "*be conservative in what you do, be liberal in what you accept from
others*".  In terms of serializations, this probably means something like:

1) If at all possible, always offer more than one alternative.  "Power
providers" should aim at more alternatives rather than fewer, to embrace as
many other VWs as possible.

2) Never make one alternative mandatory, particularly a heavyweight one
since that would tend to exclude restricted-capability clients from interop.

3) Be fluid, let progress and experience establish preferences rather than
imposing them in a spec.  After all, none of us knows what the VW universe
will be like in just a few short years, and trying to force a direction on
the Internet is like herding cats.

I believe that we're heading in the right direction already for this, in
making alternative serializations foundational.  Strong prescriptive
requirements would I think not help.

Morgaine.

On Wed, Feb 11, 2009 at 4:47 PM, Mark Lentczner <[email-masked]> wrote:

> I agree there is some ambiguity about what is the intent of having multiple
> serializations. I see several possible approaches:
>
> 2) We leave the choice up to the consumer of the data, and declare that all
> requests for LLSD must include some content type negotiation mechanism (such
> as in HTTP), and therefore all generators of LLSD must support all
> serializations.
>
> I don't support #4, because it doesn't ensure interoperability. It means
> different systems would have to advertise, out of band, what forms they
> accepted and generated.  This strikes me of being like the early days of
> TIFF format, where complaint software would often be unable to read each
> others' files.
>
> Option #3 has the easiest interoperability story.  But, unless there are
> major advantages to the non-required serializations, there will be little
> support for them. After all, once you've done the one required format, why
> do the others? We only have internal experience data to compare two of the
> formats, and not enough inter-system experience to know what would be best
> here. If experience shows that there is little practical difference between
> supporting the different serializations, then one might question why define
> alternatives.
>
> producers, then #2 would make sense. However, it does place a burden of
> content negotiation on any protocol or process that transmits serialized
> LLSD. On the face of it, I think the premise here is false: I believe that
> all sub-systems in an OGP network will produce and consume LLSD with equal
> frequency. Another argument in favor of #2 is that parsing tends to be the
> more expensive operation in LLSD transport, and different implementations
> will favor different parsing solutions, often because they match the
> semantics and/or type systems of the implementation language.
>
> If there was a substantial expense in serializing LLSD, then #1 would allow
> implementations to choose what suits them best. However, this is also not
> borne out by experience: Generating these different serializations takes
> about the same amount of work. In fact they can all easily be generated by
> the same code using a common base class and having subclasses supply strings
> for structure and a few overridden routines for string escaping and such.
>
> My sense is that we will settle on either #3 or #2. Until then, I think we
> are all operating under approach #5:
>