etorrent
etorrent copied to clipboard
jlouis
Add more storage engines to the code.
ince this is erlang it is easy to provide other storage engines than the default. Some ideas are:
- Distributed storage: Rather than store data locally, allow the system to connect to another server that has the disk on it. Easily implementable and rather smart. You can probably even build it with staging so a nodeup on the storage server automagically copies torrents to it. Etc.
- mmap'ed storage: Write a C-node that is blindingly fast and provides storage in mmap'ed form. Would be good for smaller systems with little RAM. Combined with distributed storage because a Storage API is needed first.
A user story, please? It seems to me that OS level NFS, Samba, AFS, or even iSCSI is quite sufficient.
It is an old old idea, way older than the 8 months when was added to the issue tracker. You are right that we might want to ignore it since it lacks a good story. I originally envisioned a takeover via distribution of etorrent frontends - but that can easily be had by running multiple etorrent nodes with no connectivity. The BitTorrent protocol solves the rest :)
This may or may not be related. But it is good to know we are not alone thinking about p2p and storage: http://tahoe-lafs.org/pipermail/tahoe-dev/2011-February/006150.html