> <FileList Ver="1" Generator="DC++ 0.4">
>  <Columns>
>   <Column Name="Name" Type="string">Name</Column>
>   <Column Name="Size" Type="bytes">Size</Column>
>  </Columns>
>  <Directory Name="xxx">
>   <Directory Name="yyy">
>    <File Name="zzz" Size="2134"/>
>    <File Name="ttt" Size="342342"/>
>   </Directory>
>  </Directory>
> </FileList>

perhaps also the file type ?

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?

I think there is a possible conflict between last week protocol discussion and ADC0.4 (I should have missed some mails because I have not understood how we have switched from the last week protocol (based on Fredrik's draft) with context to ADC 0.4 but it is a little detail). In the current protocol, the directory separator is the backslash (\) but in Fredrik's draft, it is a slash (/  [I prefer the slash, it is not a reserved character in C and it is easier to input on the keyboard :) ]) and in ADC, it is simply undefined. Assuming the usage of a XML filelist like described above, which separator should I use in xxx and yyy ? Except this, XML Filelist is a good idea.

Uhm, separators in the file list? XML is a tree structure, where directories
are implicitly separated, what did you want to separate in it? in any case,
adc uses the / when it's needed, all you have to do to find out that is to
read 2.2.3 where it's specified quite clearly.

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

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

typically the case where 2 commands are required, else it is all required to create buggy

You're right, I'll separate the two to avoid confusion.

clients/hubs. IMHO, ADC0.4 is only small changes to the current DC protocol which uses the current tips we use to add features to the current protocol (and command renaming), it is not a full evolution like what was discussed

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

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

/J