Stateless javascript wrapper #42
Description
Background
We are in the process of discarding the Peer class from the javascript wrapper, in #40. Objects of this class are an example of state being maintained in the wrapper, which then has to be kept in synch with the state in libtorrent and the extension. This has typically required a lot of effort, and often been imperfect, due to ambiguity and edge cases about what guarantees there are about alert order and occurrence.
Proposal
Should we take this one step further, and drop all state in the wrapper, so also the Torrent class is removed. All the remaining wrapper would do would be to give a simple interface for sending requests, and perhaps some extra support on doing some of the more complex requests related to buying/selling, and otherwise turning alerts into events emitted from a single session object. We don´t even need to have the timer for polling events.
Analysis
This will make the wrapper very simple, and will require a bit more effort in the application layer.
- Any event subscriber must filter events to make sure they are related to the torrent and peer they care about, so such a subscriber must hold to a torrent handle and perhaps endpoint
- A timer must be used to trigger regular snapshots from torrents which are of interest. Previously, the wrapper did this on its own, since it maintained a list of all torrents.