There are issues with ADC that I personally consider should be changed
or looked more deeply into.

First of all it's the message delimiter \r\n that should be changed to
\n. There is no reason to favor the current win32 implementation of
new-lines here, it only adds bug-sources to code. Splitting messages
with only one 'char' is better in every possible way I think. And this
isn't http anyway ;)

Numbers should be at least double? "double" is implementation-specific
so I guess you mean 64-bit? And then, why? This must be, just like
integers being 64-bit, state dependant. Not all kinds of data needs such
large numbers, I'd say that's a specification that should be removed
from the protocol.

As sandos mentioned in the hub chat; "Filenames outside the root are
treated as special". Outside what root? What _exactly_ are you talking
about here?

I think there should be support for binary data without base32 for
communication between client and hub (and also hub to hub if that is at
all supported), similar to the "DATA state". This might be very useful
and adds no complexity since hubs/clients that don't use it, won't need
to. Still it has to be in the protocol spec.

In the ERR message there are params and description. Since this protocol
says that message parts are delimited with space, and descriptions can
include space, how will I know what is a parameter to ERR and what is
the description? Maybe "ERR Code:Descr: param1 param2..." is a better
way, and force description not to include ':'.. It's ugly yes, but just
a note.

In INF I couldn't see an ip port for TCP. How will client A be able to
connect to client B without knowing the TCP port? Maybe I missed
something..
And when speaking of INF, "HI"? Can an arbitrary user send that info to
become invisible? I think it should be used only for special occasions
of some kind of bots. And then it's prolly up to the hub anyway to "make
it hidden", so, I really don't see the use of this.

I would like a "mode" where file sharing is disabled, a kind of "chat
only mode". That should be represented in the INF as well with HC or
something like that..

If I send a MSG how will end-lines be escaped? The regular \n (or if
\r\n for some very weird reason is preferred) will cause the next line
to be interpreted as another message/command, right?

Regarding the search, there is support for ==-searches ("Exact size in
bytes"). If this is to be included into the clients, and those clients
should be somewhat compatible to the "old" DC-protocol, then I'd say an
equal would be useful. I have for prolly a year been doing this in oDC
by letting the size-type be "don't care" _but_ sending a filesize > 0b,
which will (in oDC atleast) be interpreted as exact size. I'd say it
would be good if your clients out there, did the same.

That's it for now,
/Opera