Sometimes people (including myself) wonder why does Hydranode development take so long. I'v been at it, for like 1.5 years already, the most recent module (bt) has taken 2.5 months already - where is all this time going?
The problem with limited developer resources is that you can't slap things together, hope they work, move on, and later go back and fix things that break. It just doesn't work that way - you just end up with a ton of half-finished components, and yourself juggling between them - it can take years to properly stabilize the code then. Alternative solution is write everything right the first time; easier said than done though. The key is to approach every component of the app so that at some point, you can say to yourself "ok, this is finished", and forget about it. This way you can move on in a steady, albeit slow, space, and can always rely on earlier components to do their job.
This is also one of the reasons why I declared the Console application (first attempt on GUI-related things) obsolete - it just doesn't work. The reason was I took way too many things at once - Core/GUI comm protocol, the support library, GUI's internal data structures, and the visual representation of the data itself. You can't juggle between four distinct components - you have to build step-by-step.
Another thing you learn when developing alone for long periods of time is that you cannot afford bugs / mistakes - the cost of going back to fix something is far greater than that of writing it right the first time. This is different from corporate development, which have large resources - they have one set of developers working on new stuff, and other set of developers cleaning up the old mess; when working (nearly) alone, you don't have that luxury.
The most current problem at hand is BT module's files handling. As you know from previous posts, there are a lot of different usage scenarios there - files could be canceled from within the torrent at any point; they could be paused... or they might already be completed, or not existing anymore either. We'v approached this problem from multiple ends, the most recent being the implementation of Cache manager, which caches all cross-file chunks. Today I also added PartData::dontDownload() method, which allows customizing the chunk-selector to skip past specific ranges. It's not that simple though - if we simply mark all missing files in a torrent as dontDownload, we still need to download overlapping chunks, e.g. to cache. So basically, after marking all missing files as dontDownload, we must also unmark the ranges that cross file boundaries, since we still need those; the already complex writing and verifying code will become even more complex, since it must handle the case where files are missing, anywhere in the chunk.
In related news, some smaller issues in BT::Client were fixed (used range was never reset), uploading code works as per BT spec again, and uploadrequests can now be properly canceled. I also added
ComponentStatus page to our wiki, which gives a proper overview of various Hydranode components and their status.
Madcat, ZzZz