[hobbit] client data compression

[Henrik Størner]

In <49487A46.9020406 at websitemanagers.com.au> Adam Goryachev <mailinglists at websitemanagers.com.au> writes:

>Henrik Størner wrote:

>> It requires a new hobbitd daemon on the server side, and a new
>> "bb" utility at the client. Compression is not turned on by
>> default - you'll have to invoke "bb" as "bbz", or pass it the
>> "--compress" option.

>Sorry to continue this conversation, but I'd like to clarify some
>implementation details.

>If I have two hobbit servers, and one bbproxy server which transmits the
>data to both hobbit servers, and of course multiple bb clients behind
>the bbproxy.

>Do I need to update *both* hobbit servers, or could I only upgrade one
>hobbit server, and the bbproxy, and bbproxy would be capable of
>compressing received updates, and forwarding them to the compression
>capable server, and forwarding the uncompressed updates to the older server?

You've caught one of the "missing items" in the development version -
bbproxy hasn't been made compression-aware yet. In the end, there will
be a way of specifying whether bbproxy target servers can handle
compression or not - so yes, you could have updates sent in compressed
form to one hobbitd, and uncompressed to another.

At least, that's the plan. I haven't looked too much at the 
implementation details yet, so it might turn out differently.

>Also, how do old hobbit clients, or bb windows clients, or hobbit
>windows clients behave when behind the bbproxy? Would I need to upgrade
>each client for it's updates to be compressed, or will bbproxy handle
>that for me?

If a target server supports compression, then I think bbproxy will 
perform the compression on all of the "large" messages, i.e. status-
and client-messages. Other messages are too small to be worth the 
trouble of compressing them. So that will be transparent to the 
client.


Regards,
Henrik