What's a file type (apart from the obvious, that's identified by the
extension included in the filename)? I hope you don't expect the client to
detect the filetype by reading the files?

it should already does to index files for search.

> About ADC0.4, IMMHO, it is too heavy to use (even if the draft is not
> completed). Message types looks totally unuseful to me
> because it allows
> creation of meaningless combination of message type and
> action (like BGET).
> In fact, there is more useless combinations than useful ones.
> Why not just
> enumerate the valid commands, there are not hundreds. I think

You're missing the point. With this scheme, a client can create a new
command and have it sent to other clients correctly without any updates to
the hub software at all (if nmdch supported this, we wouldn't need a new
protocol at all, because creating a new search or myinfo command would have
been doable without having to update and rewrite all the hubs out
there...)...

This remains a big do-it-yourself, like the current protocol.

> my favorite
> command is PAS which has different parameters depending on
> the message type
> (I or H) and parameter is either base32 encoded (someone
> knows base32 ?
> know base2,8,10,16,36,62 but not 32 :) ) or md5 hash. It is

Google? It's the most common encoding for hashes for instance...

I apologize... but base32 sucks. I am reading a description explaining why it exists. The main reason of this is because I can be confused with 1, L with 1, O with 0 and U for "accidental obscenity" (seen in the documentation). We speak about a program, a program does not confuse I and 1.

Yes, the current changes are small, but they add everything that's needed
to extend the protocol in a natural and clean way, which is kind of the
point...

But it does not fix some problems in the current protocol like out of order command executions.

> last week. The context based protocol from Fredrik's draft is
> far more
> innovative (and above all, it is easier to program).

Context is captured by states in ADC, and contexts imho are a lot more
complex (considering that they in theory can be combined arbitrarily) to
implement than the 3-4 states of ADC...in fact, clients don't have to care
about them at all almost...

I partially agree. Most of the time, a client does not use more than 1 context but context is a lot easier to handle in a hub because it is basically a C structure (or a class for C++ dev.) If all conditions are required in a class, it can evolve to its next "state". The best example is IMHO the initial authentification. (I describe using current DC command) We need the $MyINFO and the $MyNick, the order has no meaning. If both conditions are met, it evolves either to the "password" state or to the "connected" state. In a group of commands, there is no need to have an order.

Eric