People keep asking me - what am I doing? What am I working on? True, I returned on monday as scheduled, but there hasn't been much (any) activity on SVN since then; furthermore, there are some rather serious bugs open, inherent from the new ClientManager (it crashes rather often right now).

Basically, yesterday and today went to hardware and software maintainance on my development systems... defraging disks, re-organizing data, and it will be concluded tomorrow early morning by reinstall of one box (Ubuntu 5.10 preview, if anyone cares). Following that, I can resume normal development routine again, and first targets are fixing the bugs introduced by the ClientManager, moving statistics handling to ClientManager (currently handled inside ed2k module), and introducing generic upload-management (which brings BT to usable state - currently it cannot upload).

Meanwhile, I got some more ideas on two topics. First, in eMule (and some other clients), there's a concept called categories - you can assign downloads to categories, have separate incoming dirs for them, can pause/resume them separately etc; these are usually implemented in user interfaces via tabs or similar. However, in Hydranode, we will need an additional concept, which I currently call download groups. These could be implemented by user interfaces as "subdirs" in the listing. They differ from categories by two things - 1. they are created only programmatically, never by user, and 2., their names are usually long. Examples of such groups are torrents, and eMule / ShareAza Collections.

The second idea is related to core/gui comm. Namely, I figure that we will need to assign a unique identifier to each operation requested by user interface; when core responds to a command, it sends the original id back. This allows more flexible management on both sides, as well as cleans up the protocol somewhat. Also, on the hncgcomm library, it will need to be re-structured - currently it exposes too much of the underlying system. Basically, hncgcomm API should mirror core API - for example PartData object would have pause(), stop(), resume(), getSources() and simialar methods. The difference here, however, is that all operations are performed asyncronously, which is where the operation ID's come in - when GUI requests a download to be paused, the request is sent to core, and the response to the operation - either success or failure - is sent back, so GUI can react. The current protocol design doesn't allow that, so GUI would simply work "blindly".

Meanwhile, while I'v been pre-occupied with other things, wubbla has been busy improving the http module. Among major code cleanups and re-structurings, several new features have been added - automatic download mirror finding (via www.filemirrors.com), automatic hashes finding (sha1 and md5, and they are checked against when the download completes), and automatic .torrent file finding (and passing to BT plugin).

Madcat, ZzZz