In any case, I (and I have understood that I'm not the only one) was
hoping that the new protocol would have standard internet CRLF command
terminators, which will solve the problem in any case.

except for multi-line parameters like chat message.

 > 3) unlike us, clients and hubs always know the size of the data to send
 > before sending them because they have built the command.

Which is precisely why we can't interact with nodes in that case. But
like I said before, the choice between a text based or binary protocol
is simply a stance we have to take. Shall we hold a poll?

a poll is probably not a bad idea but I don't know if this will produce something useful :)

Like Zdenek said in his first mail, endianess isn't a problem; after
all, that's what the htonX functions are for.

and that's also why big endian must be used because the htonX functions does nothing on big endian computer.

In any case, we need to decide on either a fully binary or fully text
protocol. There's no point at all in having some halfbreed stuff. Like
I've said, I believe in a text based protocol, since I think that both
hubs and clients have far worse things than just command parsing to
care about, but if the majority is against me, I will gracefully bow
and yield. Like I said, shall we hold a poll?

For the hub efficiency and command size (especially if we switch from nickname to ID), a binary protocol will have better performance in processing speed (no text<=>binary conversion) but also provide possibilities text protocol cannot reach like command with optional (or newly created) parameters or even command with constant parameter with different parameter type (imagine a $Search allowing either a hash ID or a pattern). However, binary protocols also have their drawbacks.

Eric