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