As a matter of fact, since June 16th, I work for IntelliJ Labs. The work I'm doing there (basically, UI development in C#) is very much similar to the work I was doing on Syndirella. Moreover, the product we're working on will include RSS reading functionality, and most likely I'll be the one responsible for designing and implementing it.

Thus, it is almost certain that I'll never even look at the Syndirella code anymore. One reason for that is IP/licensing - we want to be sure that our product is not a derivative work of Syndirella, and so I want to "forget" the Syndirella code as much as possible. And even if it were possible to settle the licensing issues (I could re-license my own Syndirella code to my employer under the conditions that I'd like to, and we could come to some agreement with other contributors), it is simply not interesting for me to do something at work and to do very similar things at home on my own time.

However, Syndirella is a GPLed project, and I want it to live. Thus, I'd be happy if the official development branch was moved to SourceForge. As soon as the new Syndirella homepage is created (and the www.syndirella.net domain is redirected to it), I'll give a pointer to that from the page at yole.ru and from my weblog. My main requirement for future Syndirella development is that yole@yole.ru should NOT be listed as the main contact address for it, and that exception reports should NOT be sent to that e-mail.

Another problem is that Syndirella uses the UtilityLibrary control library, which is not open-source. I do have the source code to it, but I don't have the permission to redistribute it. This library has been a source of many problems to me, so it would be best to create an open-source replacement for that.

Download binaries, sources or installer.

Download binaries, sources or installer.

The changes so far are not too much for almost a month's wait, but these should fix the worst problems with the previous build. The changes are:

• Autosaving no longer resets the position of the current item to the top of view.


• For items that have the content:encoded part, the content:encoded, and not the description, is used for duplicate item detection.


• Fixed problems with enabling the Back and Forward buttons.

Download binaries, sources or installer.

First of all, probably I shouldn't have focused that much on SharpReader - it's not like SharpReader is the best news aggregator that could ever be created, and I do think that the Syndirella UI is considerably more polished than that of SharpReader. But the point is, there are too many .NET three-pane news aggregators. Actually, I cannot name another case in the entire history of computing (as I know it) when so many so similar projects have appeared in such a short timespan. And I'd really like to see more collaboration between the authors of different news aggregators - since they're all so similar, it shouldn't be hard to factor out the differences, to reach a common understanding on how an ideal .NET three-pane news aggregator should look like, and to work together towards such a goal. Previously, I was certain that I knew the right way to create the perfect news aggregator UI, and I didn't really consider offering collaboration to other projects - I didn't want either to impose my vision on them or to work on implementing a different vision. But now, since I didn't succeed in implementing my vision by myself, I'm much more open to the idea of collaboration.

Another reason of frustration with Syndirella development is that Syndirella essentially sits on top of three different platforms - .NET, the raw Win32 API (used mainly by the UtilityLibrary), and the Internet Explorer ActiveX control. And the worst sources of bugs have been the boundaries of these platforms. Weird Internet Explorer exceptions, problems with the back/forward navigation, strange exceptions during Syndirella termination related to the IE control, GDI+ exceptions, Win32 resource leaks - all these problems are generally very hard to reproduce, not at all fun to fix, and many of them still remain in the current code. So now I really miss the feeling of control given by raw C++/Win32 programming (and with no stupid Visual Basic 6, which I have to use quite a lot at work, and which I so much hate). So, the idea of working on one of my pure Win32 projects now feels much more exciting.

And whatever interests me currently, I do hope that Syndirella will never "go away" - it's GPLed, and no one is going to take away the source, so there is nothing prohibiting its further evolution. And if you need CVS write access, just ask.

The point was that I'm really, really tempted to give up Syndirella development. And this is one of the reasons why. SharpReader today has just about everything that I wanted to implement in Syndirella in the next 2-3 months. So, instead of spending time creating Yet Another implementation, I'd rather continue the development of Structorian or a C++/SDL client for DungeonLab.

If anyone wants to take up Syndirella maintenance, you're welcome - e-mail me, and we'll discuss that. And if I don't find a new maintainer, I'll probably push to create the 0.91 release, and leave it at that. Maybe some time later I'll regain interest to resume working on Syndirella. Or maybe not. But for now, the fun part of the project is over, and what remains is boring hard work.

Thanks to everyone who e-mailed me and mentioned Syndirella in their weblogs, and special thanks to Johannes Technau and Keith Martin for the books. I've finished "Pattern Recognition", and really enjoyed it, and the "Spectre of the Black Rose" still sits in my reading list, but I've received it with no problems.

I'm still going to report my hacking and maybe even other activities on this weblog, so don't hurry to unsubscribe from the feed. :-) And you're always welcome to contact me by ICQ - at least, I don't leave ICQ messages unanswered, as I do with e-mail.

CY, yole. :-)

Download binaries, sources or installer.

So now I'll finally try to do the right thing: add _all_ bug reports (including the ones I can't confirm or reproduce) to the tracker, reply immediately to bug reports and specify the tracker URLs where the bugs have been recorded, and specify the IDs of fixed bugs in the new release announcements. It may be a little bit less user-friendly, but while an answer "recorded to the tracker, ID nnn" is worse than an answer "fixed in build 2003mmdd", it's still better than no answer at all.

Trivial matters, right - but I'm learning the hard way. :-)

Download binaries, sources or installer.

So I'd like to tell you about a case of using TFD in game development in which I have participated a little bit myself. When we were starting a St.Petersburg XP Users Group, we were contacted by some guys from MADia, and they told us that they were using XP for game development. Of course, I was really interested to hear about that, so I came to visit them and to see myself what they were doing and how.

By that time, they had just released their first original game, Echelon, and started the prototyping work for a future add-on to the game. One of the things they wanted to rewrite for the add-on was their menu system. The old code was quite ugly and limited, and they wanted to replace it with something that could be easily modified and extended with a standard scripting language. And they wanted to implement that in test-first mode.

I was really interested in getting some experience with XP in game development, so I offered my help with that project, and my Python expertise (which was quite limited, but still better than nothing). We paired with the lead developer of "Echelon" and together created an initial implementation of embedding Python into the game. Unfortunately, timing issues didn't let me continue working together with them, and I have basically lost the contact with them since that time.

A few months ago, the Echelon add-on Wind Warriors was released, and I bought it to see if anything remained of all the Python scripting idea. I was pleased to see that they did bring the Python-customizable UI to completion, and of course, all the Python source code was included with the game. And quite curiously, wherever I looked to read some code, I saw firstly unit tests. :-) Looks like the unit tests comprised about two thirds of the Python code.

It would be interesting to know if they used unit tests in their game logic code, written in C++, and whether they felt much gain from the tests. But still - here is an example of using TFD in games which you can examine yourself.

However, there is still one more problem that is not so easy to work around. If you start Syndirella and click on "Update all feeds", you will probably notice that the UI will get "locked" several times, and not respond to your actions for a couple of seconds. Not a proper behavior for asynchronous updates, right?

Actually, what Syndirella is actually doing when it's locked is resolving DNS host names. Although HttpWebRequest.BeginGetResponse() will download the response asynchronously, the DNS resolution is still done synchronously, and the function will not return until the DNS query is complete.

As it can be seen from the Rotor sources, the class responsible for DNS resolutions is called ServicePoint, and the query is done in its method called GetNextIPAddressInfo(). And while it is simple to do DNS queries asynchronously (Dns.BeginResolve() is readily available), it is not so easy to pass the DNS information to HttpWebRequest. So far, I have thought of only one solution not resorting to manual threading: I can parse the request URLs and replace the host name with a dotted-decimal IP address after the DNS resolution is complete (for example, a request to "home.yole.ru/weblog/index.xml" would be rewritten as "80.70.224.68/weblog/index.xml").

I don't want to implement this right now, because this will involve some risky changes. I'll need to implement a cache so that each host is not resolved on every request, and it would be best to have a limited time to live for each name resolution result (like 6 or 12 hours). But unless a better solution is found, that's what I will do in 0.92.

Hints on better ideas to solve this problem are welcome. :-)

So if you have written anything to me in the past days and got a bounce, please re-send your mail.

I'm actually searching for a paid hosting provider now, so I hope that all the outage problems will not repeat anymore. The main issue is CVS hosting - it always needs to be discussed separately, and not everyone can provide such a service. And I don't want to use the free hosting at SourceForge and similar sites. There are several reasons for that - SourceForge's occasional downtime, desire to control the repository myself, and the need to host some other projects that cannot really be called "open-source software", and thus shouldn't reside on SF.

Besides the network problems, the past week has been pretty busy for me. My birthday, its celebration with my friends from real life and from LiveJournal, my new bass guitar (it's actually sunburst colored, not black), Space Rangers (an excellent new game by a Russian company - a mix of Elite, Master of Orion and Star Control 2), a brief cold... well, you get the idea. I'll be getting back on track now.

First of all, if you ever reported a problem to me, please verify if it is fixed in the recent builds. If it is not, you should report it again. I will go through all the unanswered bug reports and try to contact everyone, but you will make my work easier if you confirm your reports after testing the latest build.

If you don't have any obvious problems, here are some tips for finding new ones. Generally, the main things to watch out for are drawing problems - specifically, drawing the list views and the toolbar. You should also check for resource exhaustion - load a lot of feeds into Syndirella, do some "heavy reading" (holding down the spacebar for a couple of seconds is a nice approximation), do some stuff with the toolbar and so on, and watch for exceptions signifying that Syndirella has run out of resources. There were some reports of resource leaks, and I've made some changes that could probably fix that, but I'm not too sure.

Another thing to be watched is the feed updates. Do all the feeds update correctly? Do you see the proper dates for feeds which have the item dates specified? Do any of the feeds get stuck in the "updating" state?

Please report problems by e-mail, not by ICQ and not by comments here. E-mail is much easier for me to keep track of.

And thanks in advance for your help!

Download binaries, sources or installer.