RE: [dcdev] Silly ADC comment
"Jacek Sieka" <[email protected]>
2004-01-18 11:18
"'Direct Connect developers'" <[email protected]>

This is not an issue really...all names in the file namespace start with /
so if you want other data than the share namespace, you just put it outside
the root (i e tth/03dddedd)...and I find it hard to imagine there being
enough many things to put outside the root that clashes will occur (famous
last words)...


-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of John Bäckstrand
Sent: Sunday, January 18, 2004 9:50 PM
To: 'Direct Connect developers'
Subject: [dcdev] Silly ADC comment

>ADC has made it to v0.4

My problem is with the GET command:

GET <type> <identifier> <start-pos> <bytes>

Firstly, type was meant to specify a namespace, and GET was only meant to
receive file-data. This is fine, in that scenario type is a namespace, and
the identifier is a identifier. They are atomically split and you wont have
to make up weird values for them (multiple identifiers that are identical in
different namespaces wont happen for example)

Now, it was proposed to let the 'type' also signify what metadata to return.
Why do I have a problem with this? Its simply aesthethic: type is now a
aggregate of 'namespace' and 'meta-data-type' (regular filecontents is a
metadata with that definition).

Here are thinkable aggregated values:


Its not unacceptable, but its just not nicely modeled. I see two ways to fix
this, one means adding a command:

1)      a) GET only takes REGULAR filenames ('file' namespace) but takes an
argument specifying what meta-data to return (of which  filecontents is one)
        b) CNV (convert) takes an identifier and a namespace and returns a
regular filename.

2)      GET takes yet another argument specifying what meta-data to return.

Note: This problem is lessened by the fact that there is only really two
namespaces: some hash (TTH) and regular filenames. If we start adding more
namespaces (I cant think of any right now though) this will get messier.

John Bäckstrand
DC Developers mailinglist

DC Developers mailinglist