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

Monday, January 03, 2005

Returning to development

Today is Jan 3rd, the scheduled date for continueing the development. The break gave me the chance to look back at the work done, as well as review and rethink the short-term and long-term goals and objectives of the project. But first and foremost, I'd like to thank all the commenters on the last blog post - frankly I was somewhat afraid of how the watchers of this project would react to 2-week break, but it all turned out pretty well. And those comments rightly reminded me that christmas was coming (which I had forgotten), and so on. So once again - thanks for that.

Now, returning to the topic at hand - HydraNode. There are several things that I'v given a lot of thought over the vacation, so let's see if I can summarize them up.

We can safely say that the first phase of hydranode development was completed in december - most of the low-level things. Also, the main focus during the first phase was well-formatted, well-documented code, high code quality standards (oh the countless hours of valgrinding), and so on. Also, the development was purely linux-oriented, with little or no support for Mac and Win32 platforms.

In the second phase, starting today, and expected to last 81 days (no, you don't need to know why 81 days - those who need to know know, those who don't, don't need to know), will be oriented towards slightly different objectives. First and foremost, the development will take place on MS Windows, which will also be the primary target platform. Linux and Mac support will be at nice to have, but not 100% required state. And before you start yelling at me - I probably can't leave linux port too much tagging behind, since the majority of my testers (and friends) are using linux. Which brings us to the next topic.

Whenever a developer writes a software, it will inevitable be affected by the surrounding atmosphere - linux-based developers design/develop software that looks, acts and feels like linux software, windows-based developers design/develop software that looks, acts and feels like windows software. The most complex aspect of cross-platform software engineering isn't the differences in the platform itself - it's the differences in the users, their attitudes and their expectations. An application oriented at Windows users doesn't really cut it at linux users, and vice versa. They are simply two different user-groups, with completely different expectations. As for Mac users - I haven't used Mac long enough and I don't have any Mac-user friends, so quite frankly, I have no idea what are their expectations.

In larger development teams, there are different people for different platforms. In case of HydraNode, however, as we all know it's an one-man-show, which makes it more time-consuming and complex than it would if a single developer had to target a single audience. HydraNode has several important basic design elements that appeal to Linux users - namely complete engine/user-interface separation. What must happen now is also make it appealing to Windows users - that is graphical user interface elements.

Starting with those, the first thing that'll need to be done is a Launcher application, which will act as shell for hydranode engine. It will start HydraNode engine as sub-process, taking over its stdin, stdout and stderr (directing them to appropriate GUI controls), provides minimal UI features (like displaying data-rates etc) and so on. This will still be a developer-UI, however, for end-user, it'll act as several modern Linux distros startup - show nice splashscreen + "Press ESC for verbose mode", optionally thus displaying the console output of HydraNode engine. This development road will eventually lead up to full user interface.

In addition to that, as mentioned previously, some components of the engine need upgrades or replacements - which will also need to be performend during this 81-day development period.

All of this leads up to the need for new development roadmap. However, while in the beginning we could clearly show a stream-lined roadmap, with clear goals moving forward, in this phase we cannot, since there are several development directions already, some of which need to be performed simultaneously, and so on. The new roadmap is still being worked on, and should be up for your viewing pleasure within a few days. The first UI design concepts of the launcher application have been proposed, but still need more work.

As for mac - hydranode is portable to Mac, but the actual porting will probably be delayed when the app is finished - it just takes too much time/energy to make it work / keep it working with my 400mhz iMac (unless ofcourse some Mac ppl volunteer to do some coding/debugging - I gladly help/introduce the codebase to whoever is interested). Personally, I can barely keep two ports operational simulataneously ... Mac port tends to be"the last feather which broke the camels back" kind of topic - and kitties with broken backs don't make good developers, now do they?

Another topic that I wanted to address in this blog post was the first HydraNode release. The roadmap put in place in June 2004 states that we should release in Jan 2005 - which is now. Today, it is clear that we will not be releasing anything in January. Furthermore, declaring HydraNode 1.0 isn't that simple after reviewing some things. While the 7th commandment declares "Release early. Release often." - it is biased towards Linux users. Windows users do not expect, nor even like software that is released pre-maturely, nor software that brings out new release every 2 days - they just think the software is buggy (which pre-maturely released software is), form first oppinion of the software based on that pre-mature version and often never come to check back at later time - been there, done that myself. Also, frequent updates make the same impression - the need for constant upgrades irritates the user, and implies the software is buggy (explaining the need for frequent updates).

For hydranode, I would consider it release-ready when it has at least 3 network support, full user interface as well as some minor side-plugins. Because if we release it as pure ed2k client, it'll be always thought of as ed2k client. Same applies to only ED2k+BT support. With three networks, we can show the power of hydranode engine, multi-network downloads and so on - only then hydranode can form a truely good first impression, shaking off all the accusations a'la "Bah, yet another mldonkey?" or similar. The new roadmap will reflect this decision, and propose new final release date - my current assumtions are around spring (making hydranode a one developer-year project), altough usable beta versions should be out far before that - e.g. in a month, or 2 at max.

Stay tuned for more details on the new development directions and roadmap over the next few days, as well as general development news over the coming weeks/months :)


PS: No, I won't apologize for loooong blog post - you can't really expect a short post after 2 weeks pause :)

Welcome back. -Avi ::still a watcher::
It's good to read another of your posts, MadCat.
Welcome back!
Happy 2005! Welcome back, madcat. I with you on nearly 90% of your assertion... I my opinion the 7th commandment is good even for win users, it's only not good for commercial software.
As I'm writing with a mac now, maybe in the future I'll help you testing hydranode also on mac.
Ciao, Simone
Welcome back!
I agree with your ideas, except in one area. I believe HN core on win32 should run as a service (like a daemon on *nix), as this would allow it to continue to run when users log on and off, and is a good way to keep something running 24/7 without affecting normal use of the machine.
Glad to have you back. See you in IRC! Simon
>Welcome back!
>I agree with your ideas, except in one area. I believe HN core on win32 >should run as a service (like a daemon on *nix), as this would allow it to >continue to run when users log on and off, and is a good way to keep >something running 24/7 without affecting normal use of the machine.

Yes. And I want mutiuser support for both platforms.
Both daemon mode and MU support have been planned from the beginning, but most likely will be implemented after everything else works good in single-user / non-daemon mode - MU + daemon is simply the next step after that.

Post a Comment

<< Home

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