Add more storage engines to the code.

jlouis commented 14 years ago

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.

edwardw commented 13 years ago

A user story, please? It seems to me that OS level NFS, Samba, AFS, or even iSCSI is quite sufficient.

jlouis commented 13 years ago

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

edwardw commented 13 years ago

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

jlouis / etorrent

Add more storage engines to the code. #18