> I see most of you talk about redundant roundtrips but this is not the only
> problem of the protocol.

This is most important problem - consider lines with more or less good
bandwidth and high latency. Lines with low latency often has a high bandwidth
but not a vice versa

> There are also issues with too many bytes sent
> across the wire.
>
> 1) All data descriptors are sent fully expanded, including NULLs and CHAR
> strings. Could be solved via variable-length encoding of the data (protocol
> internals change).
>
> 2) The server replies with a number of bytes allocated by the client
> regardless of how many actual bytes are being returned. This is okay for
> fetches when we already know size of the record packet, but this wastes a
> lot of traffic for describe/info calls. Could be solved via passing the
> buffer length as a reference to adjust it at the server side (API change).

Agreed

> Both these issues are effectively eliminated with a simple RLE compression,
> but we don't support it yet.

Again, modems (if we talk about slow lines) often did compression and
veri effective. Of course they can't lower number of roundtrips :)

> Perhaps such a workaround would be much easier
> to do than redesign/reimplement the API. Just add an optional packet-level
> compression which is enabled if and only if both sides support the new
> protocol version.

This is not enough. On lines with high latency you will see effect only
on large fetches

> The question is how to turn this feature off for those who
> already use compression provided by Zebedee or alike tools.

Those who use ZeBeDe can turn off its compression :)

Regards,
Vlad