Ämne:RE: [dcdev] XML Filelists
Från:"Jacek Sieka" <[email protected]>
Till:"'eric'" <[email protected]>, "'Direct Connect developers'" <[email protected]>
> <FileList Ver="1" Generator="DC++ 0.4">What's a file type (apart from the obvious, that's identified by the
> <Column Name="Name" Type="string">Name</Column>
> <Column Name="Size" Type="bytes">Size</Column>
> <Directory Name="xxx">
> <Directory Name="yyy">
> <File Name="zzz" Size="2134"/>
> <File Name="ttt" Size="342342"/>
perhaps also the file type ?
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
You're missing the point. With this scheme, a client can create a new
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
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 ?Google? It's the most common encoding for hashes for instance...
know base2,8,10,16,36,62 but not 32 :) ) or md5 hash. It is
typically the case where 2 commands are required, else it is all required to create buggyYou'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 discussedYes, the current changes are small, but they add everything that's needed to
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