<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 12, 2015 at 3:07 PM, Josh Adams <span dir="ltr"><<a href="mailto:josh.rubyist@gmail.com" target="_blank">josh.rubyist@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":1ut" class="a3s" style="overflow:hidden">I was curious if it would be worthwhile for<br>
someone (me?  No clue of the effort involved) to port etorrent to use<br>
this in place of its existing dht implementation.</div></blockquote></div><br></div><div class="gmail_extra">It uses a different protocol, but a great first move would be to make the protocol and the node_id generation switchable in the dht code. It is fairly close at this point.<br><br></div><div class="gmail_extra">As for etorrent, the right move in the long run is to pick parts, excise them from the system and then rebuild etorrent on top of those parts. I'd probably start by removing DHT support, reduce the system in size and then make the central components work. Then build the DHT in again. When I started that project, I had relatively little knowledge of how to think about app structure in Erlang projects, and it hurts the project quite a lot now, since things are not as self-contained and neatly isolated as they should have been. In short, etorrent requires some dedicated effort in order to bring it back into a proper shape. It is like an old beautiful car from the 60'es you've found, but the engine needs some cleaning.<br><br>-- <br><div class="gmail_signature">J.</div>
</div></div>