Bye Bye Flash Content!

Today I solved one of the topics mentioned in "Liferea Development Failures" post: the Flash content removal.

With the yet to be released 1.4.24 and 1.6-RC1 the default behaviour will be to strip Flash embedding tags from the feed content. The rationale is to prevent freezes and crashes due to Flash player issues. So if you upgrade you won't see Flash anymore...

...unless you enable it in the preferences as shown in the screenshot below.



I hope this will help everyone having a XulRunner-Flash setup to tends that crash/freeze and all those using Webkit and having problems with the DSP device locking.

Redesign Feedback

There was a lot of feedback to my last post about a rewrite/redesign of Liferea. Practically everyone agrees with the performance problems to be the top priority and most of you believe that a rewrite is the way to go.

Current ideas include further improving the UI code to simpler and conceptually clean GObject implementations (suggested by Arnold Noronha) and redesigning the Liferea core to use a task handling solving the performance issues as implemented by GTask (suggested by Christian Hergert).

Several commentors mentioned a missing general plugin system for easy extensibility. It may be that such a plugin system might motivate the one or the other to hack some quick add-on and might get more advanced users interested in doing things with Liferea.

For everyone who contacted me via blog/chat/mail: Let's wait till coming sunday to gather all feedback and then make some plans. I plan to collect everyones topics of interest so we can make a list and organize appropriately.

Rewrite/Redesign From Scratch

One of the commentors of the previous post pointed out the possibility of a clean start without rewriting the existing code base. The idea being that there might be people willing to start from scratch while unwilling to dig through an existing code base.

As of now, despite continuous attempts, I'm not successful with motivating developers to actively and long-time participate in Liferea development. Maybe a new restart with the same or another project name. With me or someone else leading everything. With the goal to provide an better alternative to Liferea.

So is there anyone out there, reading this, willing to start a new GTK or GNOME feed reader project in C or C++ in the next two months? Feel free to comment or contact me directly!

The alternative will be a redesign of the existing code.

Liferea Development Failures So Far

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.

Liferea v1.2

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.
  

Liferea 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.

Liferea 1.8 or 2.0?

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!