This issue can be closed as resolved. Way cool!

another interesting link, regarding hashes to be included: 
http://wiki.depthstrike.com/index.php/P2P:Protocol:Specifications:Optional_Hashes

Hash cache redesign largely finished, and in testing now.

Torrent support working already in trunk. Now figuring out things like updating 
the tracker servers, and exact bittorrent format that is suitable for as many 
clients as possible.

This requires a hash cache redesign -- tracked in issue 40.

Links about generation of torrents:

http://en.wikipedia.org/wiki/BitTorrent_(protocol)#Creating_and_publishing_torrent
s
http://www.bittorrent.org/beps/bep_0003.html
http://wiki.theory.org/BitTorrentSpecification
http://en.wikipedia.org/wiki/Bencode
http://pypi.python.org/pypi/BitTorrent-bencode/5.0.8

Looking further, this is all straightforward - metalink-hasher could provide the 
hashes in a form digestible by Apache, and they would contain all that's needed. 
Apache could easily generated the torrent live.

However the question arises whether it might be better to have real .torrent files 
on disk (and maybe even next to the original files), simply for two reasons:

- they can be mirrored then
- to run a seeder (I'm not sure about the exact needs of seeders, but I suppose 
they benefit from already prepared torrent files)

For practical reasons, the latter might be more important than the former.

Darix suggests as first approach to hack make_torrent calls into the python 
thingie (metalink-hasher).

See http://www.rasterbar.com/products/libtorrent/examples.html

Darix suggests to talk to hydri in #libtorrent.

Vittorio suggested that the metalink-hasher might create torrent files along the way.

The metalink-hasher is a Python program which walks the file tree and looks what needs 
to be done; it calls the "metalink" binary which is a standalone binary.

Darix suggests to look at make_torrent example from libtorrent-rasterbar and either 
call that or even link libtorrent-rasterbar into metalink. That way you only need to 
read each block once for hashing.

http://www.rasterbar.com/products/libtorrent/
http://www.rasterbar.com/products/libtorrent/client_test.html

Maybe metalink could be extended easily to do the same. Or, maybe the output of 
"metalink" could be used - after all, it outputs a series of hashes. However, maybe the 
blocks would not fit?