[sldev] Google data exchange format

[Jordi Polo]

Protocol buffers compared with JSON should be much faster and much compact.
I guess the closest thing is ASN1, but the Google proposal seem much simpler
(or may I say more ad-hoc).
What I am not sure how it compares with is Thrift (
http://developers.facebook.com/thrift/ ). It seems mostly the same.


On Thu, Jul 10, 2008 at 8:29 AM, Christian Scholz / Tao Takashi (SL) <
tao.takashi at googlemail.com> wrote:

> Indeed, thanks for the link!
> I just tried out the Python version and tried to got it running inside
> a buildout. Works now but could be packaged better IMHO.
> I might test this with pyogp by implementing a new serializer with it.
>
> As what serialization to use is still a question though as all have
> their advantages and disadvantages. e.g. JSON would have the advantage
> of being known to many developers. But Google has some weight so
> protobuf might also be somewhat known very soon while LLSD probably
> not so much. As for efficiency it will probably also come down to
> protobuf.
>
> But as OGP hopefully allows not only one serialization it should be
> fine. We just need a way to let components find out what
> serializations are supported.
>
> -- Tao
>
> On Wed, Jul 9, 2008 at 8:06 PM, John Hurliman <jhurliman at jhurliman.org>
> wrote:
> > Thanks for the link. I'm in the process of adding C# support, and if I
> have
> > time I might reimplement a few SL packets as protobufs to do comparisons.
> If
> > a few tweaks were made to allow mostly empty byte arrays to pack down
> (I'm
> > thinking LayerData), zerocoding would become unnecessary and you remove
> one
> > of the most complex* parts of a high performance implementation of the
> > network layer. The only change I would probably make would be adding
> native
> > support for important datatypes (vector2/3/4, quaternion, uuid). Being
> able
> > to throw away the message template and the three different serialization
> > formats of LLSD and replace them with a single fast and terse
> implementation
> > would be very nice.
> >
> > Still can't figure out why the release build of libprotobuf.dll is over
> > 700KB though. More digging required.
> >
> > * Allocating a new ~2KB block of memory every time a zerocoded packet
> comes
> > in or goes out is going to fragment memory really quickly. To get around
> > this you need a dynamic pool of buffers to pack/unpack messages, and
> handle
> > checking in and checking out buffers to the pool (like a threadpool for
> > memory chunks).
> >
> >
> > John
> >
> > On Tue, Jul 8, 2008 at 1:32 PM, Argent <secret.argent at gmail.com> wrote:
> >>
> >> Just announced on slashdot:
> >>
> >>
> >>
> http://google-opensource.blogspot.com/2008/07/protocol-buffers-googles-data.html
> >>
> >> A fast, compact IDL that's got a well-tested open-source implementation
> >> and is an order of magnitude faster than XML?
> >>
> >>
> >> _______________________________________________
> >> Policies and (un)subscribe information available here:
> >> http://wiki.secondlife.com/wiki/SLDev
> >> Please read the policies before posting to keep unmoderated posting
> >> privileges
> >
> >
> > _______________________________________________
> > Policies and (un)subscribe information available here:
> > http://wiki.secondlife.com/wiki/SLDev
> > Please read the policies before posting to keep unmoderated posting
> > privileges
> >
>
>
>
> --
> Christian Scholz
> Tao Takashi (Second Life name)
> taotakashi at gmail.com
> Blog/Podcast: http://mrtopf.de/blog
> Planet: http://worldofsl.com
>
> Company: http://comlounge.net
> Tech Video Blog: http://comlounge.tv
> IRC: MrTopf/Tao_T
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting
> privileges
>



-- 
Jordi Polo Carres
NLP laboratory - NAIST
http://www.bahasara.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080710/f1519689/attachment.htm