[sldev] Google data exchange format
Mark Lentczner
markl at lindenlab.com
Thu Jul 10 13:55:14 PDT 2008
Intriguing as Google Protocol Buffers are, they do not look like a
reasonable replacement or serialization for LLSD.
GPB requires a single, central line of "truth" for evolution. For
example, it isn't possible for Alice and Bob to both work on
extensions to a given message: The field numbers will collide. At some
point, if both extensions are to be used, they must be merged and one
or the other renumbered. At that point, all data in the wild for the
renumbered extension now must be carefully eradicated, lest being
confused for the other extension's data.
In contrast, Alice and Bob can both work on extensions in LLSD with
far less of this problem. Either they can just choose names for their
extended fields and assume they won't collide (most common), or they
and prefix their field names for uniqueness.
While not perfect, LLSD's full self-description of field names better
enables simultaneous development. Of course, it extracts a price for
that in bytes over the wire and in memory.
GPB is much more like the Message Template system, though somewhat
more flexible than the current Message Template in several ways.
Nonetheless, doesn't seem much of a huge win to convert at this
point. As for the implementation of Message Templates - I'm SURE that
it can be improved upon with far less work than converting to GPB
would entail.
As their announcement guessed, I'm thinking "Yet another IDL?" I
recognize that most existing systems have grown complicated (though
will GPB go this route too?), but several of them are well-supported
standards. Since GPB doesn't seem to improve any particular aspect of
them (only simplify and sub-set), I'm not sure why they didn't just
use one.
LLSD goes in a distinctly different direction. It is a different sort
of IDL, describing a much looser coupling, expressly trading
compactness and strictness for long term deployment and evolution. I
still think we should be using LLSD for all OGP interaction.
(Serialization, whether XML, JSON, or binary is a separate matter.)
> Thanks. I seem to recall that Zero announced that LLSD binary would
> be deprecated because he couldn't' find anyone who was using it.
> Zero did not look very hard. We use llsd+binary for at least 2
> different major internal systems ...
I believe I was looking for places where LL's use of LLSD binary is
exposed between sim and viewer.
- Zero
Mark Lentczner
Engineering Director
API & Architecture
Linden Lab
markl at lindenlab.com
Zero Linden
zero.linden at secondlife.com
More information about the SLDev
mailing list