Zdenek Stangl writes:
> hi, just a few quick thoughts from my points of view:
> > - no hub-side data compression. There are still low-end hubs
> running 1000+ users

Like Jernej said, isn't it better to make it optional? That way the
hub owner can decide the policy depending on his CPU or bandwidth. The
hub can simply:
1. Not request compression (For low-CPU hubs)
2. Request compression (For high-end hubs, make the client decide)
3. Require compression (For low-bandwidth hubs)

Like Jernej also said, I think encryption should be considered as
well. There are several good reasons, including the ability to
authenticate on certificate basis (for ops, for example).

> - for commands format i would prefer either
>   a) short fourcc header for every command with command type and
>   data length. Therefore no command separator and no
>   newline/space/or_whatever escaping is needed (I know, the
>   byte-order differences on various OSes but hey, sockets
>   implementation deals with the same problem and it's working
>   fine... htons, ntohl etc...  what's faster? Swapping of two bytes
>   from the header or parsing the data for [end] separator? Not all
>   messages are sent in one piece...)
>   or b) let the command is zero-terminated string without length in
>   the header. But then we are back in searching for data-end.

I do not agree with you. Although binary protocols admittedly have
advantages, it isn't that hard to implement quoting anyway, so why not
simplify debugging and monitoring by using a text-based protocol
instead? When it comes to using CPU power, there are far greater
problems in a DC implementation than protocol parsing. Like searching,
for example.

I do agree that there should be fourcc commands, though, unlike
DN-TNGs idea of using command strings. Fourcc commands simplifies
things for all parties. In most else I agree with DC-TNG, though, for
example having CRLF line terminators for consistency with other
Internet protocols.

Thoughts?

Fredrik Tolf