To publish more than one file, you have to either archive them, or
publish a number of links (one link per file).
Magnet URI specs mention a manifest topics - special files that work
roughly as torrents in that they contain a list of hashes (technically,
they contain a list of normal magnet URIs, but in any magnet the main
thing is a hash anyway).
Manifest could be anything (magnet specs are very general and
application-independent). xml file list could be considered a form of
manifest. Another format for manifests is MAGnet MAnifest format (MAGMA).
So i thought it would be cool to have support for something like that in
DC++.
What needs to be done:
1) handle &mt=<manifest topic> keyword in magnet URIs
Mt may be a hash or any valid web link. DC++, for example, should either
1a) start searching for a file with the manifest's hash (if it's a TTH)
and download it, or
1b) download a manifest from the web (use HttpConnection?) if it's a
http:// link.
2) Once file is obtained - parse it and display its contents to the
user, offering to download the files inside.
2a) File could be obtained by 3rdparty application (usually - web
browser), saved to disk and passed to DC++. With *.magma extension it's
easy - just set up the .magma handler in registry. It should looks like
"%program fiels%\bin\DCPlusPlus.exe" manifest "%1". With other file list
formats...dunno. *.xml and *.xml.bz2 both aren't really DC++-specific.
Maybe introduce *.dclist or something like that?
2b) DC++ assumes that commandline consists only of a dchub/adchub/magnet
link, everything else is ignored. Since manifest is passed as just a
file name, it's not possible to identify it by URI prefix (such as
"magnet:?"). Commandline parser has to be changed to recognize various
arguments.
2c) Obviously, DC++ needs magma-parser to parse magma files.
2cI) Magma is just a list of magnets. No information about directory
structure. So, maybe it's better to stick to dclists.
I've tried to implement these (patch attached). Alas, my skills in
hardcore C++ aren't as good as i hoped, so you shouldn't assume that
it's bugless or even compiles out of the box. I just don't know how to
do some of the things.
I've more or less made the 1) (also, now magnet parser knows how to
handle multiple keywords, such as "&dn.1=foo&dn.2=bar")
I've tried to do 1a), but filed - file is added the the download queue,
but something wrong happens and it is never downloaded (DC++
continuously requests the file from a peer, but peer says that file is
not available or unknown).
1b) is not implemented
2) is complicated by the fact that everything in DC++ is tied to user
IDs, but there is no specific user behind a manifes or a file list
obtained from &mt. I've used DirectoryListing to show the list.
For 2a) i've done this manually (via registry editor), and only for
.magma extension
For 2b) i've made a simple commandline parser. Barely working, but still
better than string::find()
For 2c) i've made a magma parser. Magma specs are awkward. Maybe magma
v4.x will be better, but it is not released yet.
As i said, it's just something to think on, not a really working thing.
Also you may consider:
Parsing &kt=<search key words> and initiating a search.
Use &xs=<exact source> to point to a peer cache (AFAIK Gnutella does that)
Use &as=<acceptable source> to download file from a web (&as is never a
hash) when search yields nothing.
Set up a http listener in 451xx port range according to magnet URI
specs. AFAIK only Azureus supports such technique. DC++, being
inherently Windows application, relies more on magnet.exe and the
Windows registry.
|
