Speaking of saving bytes, it was mentioned on this list a longer time
ago, and for some reason rejected:

The idea of using Google Protocol Buffers instead of the currently
rather unflexible implementation of LLSD.

http://code.google.com/intl/de-DE/apis/protocolbuffers/

The protocol buffers serve pretty much the same purpose, are less
verbose, and support -optional- fields,
which means that in some cases quite alot of overhead could be saved.
Headers and cpp files for the
messages can be autoconstructed as well. Worth a look, IMO.

On Thu, Apr 2, 2009 at 02:21, Lawson English <[email protected]> wrote:
> Soft wrote:
>> Fuller protocol documentation is on the long list. But ask away any
>> time if there are specific fields/messages you're curious about.
>>
>> On Wed, Apr 1, 2009 at 5:18 PM, Thomas Grimshaw <[email protected]> wrote:
>>
>>> In order for that to be accomplished, it will be massively helpful for
>>> somebody from the lab to spend some time updating the protocol details
>>> on the wiki with information on which parameters do what, etc.
>>>
>>> While the community (libsecondlife / opensimulator) have deciphered a
>>> majority of the messages, nothing is certain or definate, and having to
>>> reverse engineer something which is technically open is a little
>>> counterproductive.
>>>
>> _______________________________________________
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/SLDev
>> Please read the policies before posting to keep unmoderated posting 
>> privileges
>>
>>
>
> Hey check out the AWG docs, Libsl docs, and the inline packet handlers
> Enus made for pyogp.
>
> L.
> _______________________________________________
> 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

Reply via email to