Ämne:
Re: [dcdev] XML Filelists
Från:
eric
Datum:
2004-01-21 2:58
Till:
Direct Connect developers <[email protected]>, "Jacek Sieka" <[email protected]>


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

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.

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 ? I 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 buggy 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 last week. The context based protocol from Fredrik's draft is far more innovative (and above all, it is easier to program).

Eric

-- 
DC Developers mailinglist
http://3jane.ashpool.org/cgi-bin/mailman/listinfo/dcdev