27 February 2007

Liferea & GNOME

During several code reorganisations for the slowly progressing sqlite support I thought a lot over the ugly things in Liferea (podcast support, media playback, own network code, proxy preference) and ways to overcome them. One conclusion was that one reason for those quality problems is the missing platform. Its hard to admit but Liferea's platform SW stack is to small.

Examples for this is the need for high-level rendering provided by libxul while at the same moment implementing own networking. Or of searching for a way to play podcasts and use the ugly solution of a Flash plugin.

The topic of using GNOME was discussed on the list some times and I usually argumented with high efforts and massive dependencies. I now think at least the first point is incorrect and the other point might have lost its strength because I believe most users running Liferea along with a GNOME installation.

So should Liferea move to GNOME? Are there more benefits than repelled users? What do you think?

To get more opinions on those questions I did ask for advice on gnome-list@gnome.org. If you are involved with GNOME and use Liferea please join the discussion there!

24 February 2007

DB Backend Progress

Here is a short update on the 1.3.x progress. The promised comments support already works properly and is available from SVN HEAD. The rewrite with a DB backend using sqlite has started and there is a first prototype able to load and write items to the database. During the first integration work the necessary work became much clearer and I think the effort is now more predictable. My current estimation is somewhere between 3 to 6 months until a first stable version.

As always I want to motivate everyone to join development. You don't need to bring anything with you beside a little bit of C coding knowledge and time to spend. After all how many users are out there? And what is a good user/developer ratio? While I think 100/1 might be normal is 1000/1 also ok? Anyone knowing about typical open source numbers?

08 February 2007

Item Duplicate Detection

The new release 1.2.6 introduces a solution for item duplicate detection. My goal was to make a simple unobtrusive implementation that will avoid encountering the same article twice as unread.

Here is what it does:
  1. When rendering an item which is duplicated in other feeds there will be an extra "Also in [feed]" header line for each feed with a duplicate.
  2. When changing the read state of an item with duplicates the read state change will be propagated to all other duplicates.
An open problem is the question what should happen when a new duplicate item arrives after reading a copy of it. Should it be added as unread or changed to match the state of all other duplicates? Is one interested in the fact that a new blog posted the same item?

Well the current implementation does add the new duplicate as unread (leaving the older duplicated items as they are). This has the advantage of being noticed that the item was posted somewhere else. But depending on the spreading time of an item (maybe due to slow planet updates) this might be unpractical. Therefore please give it a try and tell me of your experiences!