dcdev mailing list

<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

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

Maybe a date to?

Which date would that be? In most cases it'll be the date that the person
downloaded the file...

/J

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Works for me :)

On Wednesday 21 January 2004 12:04, Jacek Sieka wrote:

...and I forgot...

<FileList Ver="1" Nick="arnetheduck" Generator="DC++ 0.4">

- -- - -janvidar-

Dj Offset / QuickDC
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFADlpOMLjmoUcyZAoRAuPaAJ0aqj8oCV47MaGR3DHsePJOtLhpOACgr+2K
BwL6MtAqNIui1NTnMDe1hqY=
=Pkos
-----END PGP SIGNATURE-----

DC++ (and adc) is soon going to get XML filelists...here's a suggestion as
to what it should look like:

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

The columns description should map every attribute to a type and english
name so that earlier clients can view the extra info from newer
clients...it's valid all across the tree, including directory attribs.

Comments?

/J

...and I forgot...

<FileList Ver="1" Nick="arnetheduck" Generator="DC++ 0.4">

Maybe a date to?

Meltingfire
[email protected]

"Jacek Sieka" <[email protected]>
Sent by: [email protected]

2004-01-21 12:04
Please respond to Direct Connect developers        
        To:        "'Direct Connect developers'" <[email protected]>
        cc:        
        Subject:        RE: [dcdev] XML Filelists

...and I forgot...

<FileList Ver="1" Nick="arnetheduck" Generator="DC++ 0.4">

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

it should already does to index files for search.

Yes, but it doesn't read the file's content to classify their type...at
least any client I'll be writing in the near future won't have a built-in
type detector for all possible types out there...

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

Well, then you tell me the reason why it's in wide use and not something
else?

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.

Well, you're saying it yourself...change all occurances of "state" to
"context" in the adc description and you'll see a striking similarity...
I don't know how you plan to write your context driven machine, but the
client will be striving to reach a certain target context set, and to reach
it it has to pass through a number of other context sets (which both you and
adc calls states), and in a particular order at that (or did you want to
send the password before you know whether it's needed?)...although while you
will be evolving, adc will make a transition...

/J

eric wrote:

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.

Hello, you might be interested in reading this thread, from the p2p-hackers mailing list:

http://zgp.org/pipermail/p2p-hackers/2001-September/000312.html

Base32 is a good encoding scheme for representing hashes.  Having more than one binary-represented-in-ascii scheme in the protocol (ADC or not) is a liability.  Please see that.

- Todd

As I've stated numerous times, one of the great advantages of contexts
is that they can be used to support protocol extension arbitration. If
some client introduces protocol extensions (as will happen, whatever
protocol you decide for), it can put the additional commands a context
called "myext" or something. Then, to see if the other side supports
those extensions, it will simply request that the context "myext"
should be added, and if the other side agrees, all is well and those
commands may be used. That is the primary reason why I want the
contexts to be named.

With contexts, we have a more "object" oriented protocol where each context is basically self-sufficient.

Eric

eric wrote:

http://zgp.org/pipermail/p2p-hackers/2001-September/000312.html

Base32 is a good encoding scheme for representing hashes.  Having more
than one binary-represented-in-ascii scheme in the protocol (ADC or not)
is a liability.  Please see that.
  

Did they not also say that base64 is better (shorter) ?

Did they not decide that the benefits of base32 outweighed the benefits
of base64?

- Todd