Wednesday, June 10, 2009

XPCOM Bittorrent Tracker IDL

Here's the working copy of the IDL I'm working on for the Bittorrent tracker component.

#include "nsISupports.idl"
#include "nsIVariant.idl"

[scriptable, function, uuid(a2a97e13-ddab-4a8c-a72e-45f3c26e5dce)]
interface nsIBittorrentInformation : nsISupports
nsIVariant get(in ACString key);

[scriptable, function, uuid(8bd92751-6566-4e8c-9d65-9a84195876d9)]
interface nsIBittorrentTrackerListener : nsISupports
void update(in nsIBittorrentTracker tracker, in nsIVariant information);
void onError(in nsIBittorrentTracker tracker, in nsIVariant information);

[scriptable, uuid(eb4f9895-e19a-4655-95d6-de801075e303)]
interface nsIBittorrentTracker : nsISupports
void init(in ACString announceURI, in nsIBittorrentInformation infoSource);
void start();
void stop();
// boolean forceUpdate(in boolean ignoreInterval);
void addTrackerListener(in nsIBittorrentTrackerListener listener);
void removeTrackerListener(in nsIBittorrentTrackerListener listener);

BittorrentInformation is just a simple map, the source for finding basic information about a torrent: info_hash, peer_id, port, uploaded bytes, etc. Perhaps this should be an interface with those attributes? At the moment, I find the thought of adding more and more interfaces for simple information a waste, but would be glad to hear differing opinions. I expect if the key isn't found, then an exception would be thrown.

The listener is for receiving the tracker updates, or errors if the tracker has issues. For example: a PeerManager may listen for tracker updates to record new peers.

I've thought about adding fancy extras to the Tracker, (eg. force updating, setting auto-retries) but this seems like predicting usage of the component before there's actually usage. Hoping to keep it simple.

I expect that the components implementing these interfaces will be completed this week. I'm also expecting to migrate new code from the current firewalled SVN repository to Google Code (Bittorrent4XPCOM).

Nice to be back at work.