Alo Sarv
lead developer

Donate via

Latest Builds

version 0.3
tar.gz tar.bz2
Boost 1.33.1 Headers
MLDonkey Downloads Import Module Development
Payment completed
Development in progress.
Developer's Diary

Tuesday, December 07, 2004

Simplification is the key

Today it finally hit me - the key to stabilizing this thing is simplifications. Seems I forgot the 13th commandment: "Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away." - Antoine de Saint-Exupéry. It's painfully obvious that this is what we need.

Following this rationale, I rewrote Client::DownloadInfo chunks handling code, replacing it with significently simpler implementation - got rid of over 100 lines of error-prone code, and replaced with a nice simple 5-line function. Now downloading on ed2k module side is pretty stable. Which, however, can't be said about core side.

After fixing few bugs in range management subsystem (you know - the 1600-line header-only engine which is accompanied with a 1000-line regress-test and acts as backend for PartData), it's clear to me now that PartData implementation is too complex and error-prone. It currently has SIX different internal data structures, storing various rangelists and things. Keeping all that in sync is a constant headache and highly error-prone, which explains why I haven't managed to stabilize it thus far. The entire using/locking mechanism needs to be reviewed and simplified to the point where it becomes maintainable again, I definately over-engineered that thing.

Another thing that's hitting me again and again is the damn events. It's been scheduled for rewrite for quite some time now, but now other things are waiting for that rewrite already - the multi-handler calling isn't working with current implementation. The interface also needs re-design, since it's error-prone (forgetting to remove your handlers?), non-intuitive syntax and too coupled with the underlying event object. The new implementation should be completely decoupled from the object an event table refers too - this is needed to allow smart-ptr-based event tables and so generally more flexible usage.

You might think - write events? You nuts? Isn't it the base of the entire app? Yes, it is. But that's the beauty of this thing - I can rewrite any part of it w/o much problems. Another thing - you don't truly understand a problem until the first time you implement a solution. Most subsystems in hydranode have gone through at least two implementations before reaching their final versions - and events are still in their first incarnation.

On other news (besides the one that I have a terrible headache again ... stupid winter), I figured the build system really needs an upgrade, so I delved into GNU auto-tools system. The new system is now deployed, works and is DAMN cool :) Those using CVS versions, refer to the commit message for instructions on how to build it. Note that you need GNU Autoconf 2.57 now too (doesn't work with lower versions). Note about debian woody - it has gcc 2.95 (which is unsupported), and autoconf 2.53 (also unsupported). While we could rather easily lower autoconf requirement down to 2.53, it wouldn't help much, since gcc 2.95 will remain unsupported. So - those who have upgraded their gcc on woody can imho as well upgrade the rest of the build tools, so I see no point currently downgrading autoconf requirement (unless someone gives me a good reason ... )

Also - if you have ideas for hydranode GUI, feel free to drop them to this forum thread.

Madcat, ZzZz

This post has been removed by a blog administrator.
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?