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, September 26, 2005

Fixes and improvements

Yap, it's monday evening (according to my schedule, anyway), and I don't have the new Client API yet. Instead, I have some fixes, some improvements, and some additional designs on Core/GUI comm topic.

To get the usual listing out of the way, here it is:

Now, with that out of the way, we can get back to the interesting stuff. I realized I went all wrong with the cgcomm library - it was just hacked together w/o proper design. What must be done is a full API design for the library; it should act and feel like it was direct link to core, completely hiding the fact that the core is actually a separate process. Basically, it would almost duplicate much of the hncore API (but not hnbase), providing proper iterator-based interface (we all love iterators, don't we? :)), signals on updates and so on and so forth.

On top of that, we will have QT Model classes (derived from QAbstractItemModel or similar), which wrap around the cgcomm library interface; and on top of that, we will have QT View classes (QAbstractItemView and derived), which finally expose the entire thing to the user. This design fits nicely into QT Model/View Programming architecture, and decouples GUI handling from the data, allowing any of the components to vary independantly; here we even have two layers - cgcomm library, which allows user interfaces to vary and QT Model classes on top of that, which allow views to vary (we can provide different views of same data structure very easily).

On the GUI topic itself, I figured since I don't have the designer resources right now to accomplish the most ambitious goals, I'll have to scale back the requirements, and (at least initially) come up with a simpler UI, that's mainly based on native/default controls; since all of hydranode is so damn modular and so on and so forth, we can swap out user interfaces, or parts of it very easily at any point down the road, when better resources become available.

Madcat, ZzZz

Are you going to implement something like the "max. half open connections" in eMule, since WinXP SP2 users (w/o patch) are limited to 9, but others can set a higher value.
This patch took care of the XP/SP2 limitations, as noted in the list. Currently I see no need for additional patches. XP/SP2 limitation is "new, incomplete outbound connections per second", and defaults to 10; while this patch also counts incoming connections towards that value, it stays below that limit nonetheless.

Of course you can always patch your tcpip.sys to increase the limit
Post a Comment

<< Home

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