From time to time it helps to look back and to reflect on the results so far. When doing so you do sum up your success stories and your significant/total failures. I want to focus on the latter ones for this post.
Let's exclude the v1.0 branch as the initial implementation of features and start with the goals and their results of the v1.2 line:
- Fixing 64bit Instabilites: In fact v1.0 was unusable on x86_64. During the year to reach v1.2 a lot of patches and debugging went into the stability issues and reduced the crashes. But never completely, v1.2 still crashed. Later when the last issue was fixed during v1.4 preparation the most crashes where caused by the HTTP-client code.
What should have been done: not having own HTTP-client code would have skipped almost all of the 64bit problems. But due to missing GPL'd network libraries for C supporting cookies this was not possible at the time. Right now v1.5 switched to libcurl.
- Correct Locking: With v1.0 a lot of users had problems with the locking of the cache directory (XML files that only one instance could write at a time). Crashes often lead to stale lock files and the running instance detection not working perfectly often prevented removing the lock file. The result was an annoying dialog warning of a (not really) running instance.
What should have been done: Use a standard locking mechanism ripped from another reliable open source project. Done after 2 years later by using BaconMessageConnection from libbacon of the GNOME project with v1.4.
- XulRunner Flash Crashes: Starting with Flash 9 (now 10) Liferea when running Flash applets in the GtkMozEmbed widget on 64bit systems very often crashed and as often just froze the application. Both behaviours unacceptable and causing dozens of bug reports.
What should have been done: Note: there is no reasonable way to disable Flash in GtkMozEmbed. So the only thing left is a HTML postprocessing stripping all <embed> and <object> tags to not even allow execution. Sadly it's still not realized. Also starting with v1.5 the renderer is switched to Webkit which is much more stable and faster than GtkMozEmbed.
- Fixing Slow XML Cache: That's the #1 failure in the Liferea development so far. After a lot of discussion in the mailing list a lot of people hinted about using sqlite as a leight-weight DB backend. And in fact coding against sqlite is pretty simple, runtime stability and version compatibility is good too. The thing is you have to know about the downsides of sqlite:
- Heavy disk activity (Firefox3 Places users are suffering too).
- Continuing DB fragmentation and no runtime auto-reorganization.
- Very long startup time for fragmented DBs (e.g. 30s for 50MB).
- VACUUM (the manual reorganization SQL command) not working when you JOIN on ROWIDs. This I never read in the sqlite documentation but a user gave this hint.
Right now there are many users dropping Liferea for excessive startup times and temporary freezing when doing massive feed updates.
What should have been done: I'm not even sure. The XML based cache was as slow as sqlite is now when it got large enough and it also caused a lot of disk accesses. The only really advantage of the DB is easier search folder rule implementation and simple transaction based migration.
So what's in for the next release cycle? When asking what users would care most about it then it is PERFORMANCE. The question remains what to change? Right now I think using sqlite is not wrong itself, but the schema might have to be changed significantly and the expensive use cases (search folders rules) should not be realized using SQL views. To change this the feature and others might need to be removed altogether. Additionally in-memory caching of items (e.g. all unread) might be wise as they will be accessed with a high-propability anyway. When thinking about it changing the features in favour of performance means having a v2.0 line mercilessly reducing features eliminating everything effecting runtime performance.
Feel invited to comment your opinions and experiences!