eric writes:
> > > 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.

However, that's what quoting is good foor.

> > >  > 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 :)

Actually, I was thinking the same. ;-)

Maybe we should create some test data, a binary parser and a text
parser, and compare their performance?

In any case, I think we should decide on a protocol ASAP, so that we
can begin to decide on the internals of it. How about we do that test,
present the data somewhere on the net and let people choose?

> > 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.

Why do you mean that text protocols cannot handle optional or variant
parameters? I see no reason for that.

As I see it, the only thing that speaks in favor of a binary protocol
is parsing speed. That is also why I suggest the test I mentioned. I
would also like to see the result of profiling a complete hub
implementation, to see how much CPU time command parsing takes in
proportion to the rest of the stuff. If command parsing takes like 10%
or less anyway, I think a binary protocol won't do enough difference
to be considered advantageous.

Fredrik Tolf