20 December 2006

Plans for 1.3.x

After 1.2 is released (and will get some more maintaince) I want to outline my plans for the 1.3 unstable branch. The idea is to get the same good feedback as with all the different 1.2 features. And maybe to convince you to contribute code and own ideas!

My Ideas
  • Replacing the XML file backend with sqlite
  • Simplify preferences dialog
    • removing memory/disk optimization
    • removing the browser module selection (use priority based plugin loading instead)
  • Main menu redesign (another HIG compliance discussion)
  • Rethinking the suboptimal libnotify popup presentation
  • maybe: extra enclosure download queue (with serialized or only partially concurrent download to avoid eating all bandwidth)
  • maybe: better redirect handling (as discussed some while ago)
  • maybe: replacing networking backend (to avoid having own code)
Additionally ideas? Want to work on some of those topics? Feedback!


Sean Dague said...

A feature I'd really like to see is an easy way to make a menu hook for liferea articles. Having plugins add functionality like:
New Blog Entry (which runs a command)
IM to -> (possibly able to pick people off a gaim buddy list)

None of this would need to be built into Liferea per say, however if there was an easy way to register a new menu item to run a command with some standard variable substitutions, that would be quite nifty.

Anonymous said...

Liferea should get a major speed improvement.
On a 3.2GHz Pentium, changing current feed takes ages. I have 13 folders with maybe some 100 different feeds.

Best aggregator I know! I'd wish it'd be available for Windows aswell ...

Petar said...

>Replacing the XML file backend with sqlite

This should be priority 1.

Some import/export features would be great.

Thanks for doing a great job!

intangible said...

Some way to sync read/unread feeds between usage locations (home / work)

Ability to remove / change toolbar buttons (I hate it when I accidently mark all as ready instead of jump to next unread)

Other than that, liferea is close to perfect! :)

stuffcorpse said...

sorting feeds in folders? and if i can select multiple feeds at once and do something, e.g. move/delete would be awesome.

Lars said...

Thanks for all your feedback. I try to summarize my thinking of the suggestions (Blogger needs threaded comments!):

@sean dague - menu hooks: Good idea providing a method would not be much effort but could make some interesting use cases reality. There are two problems that would need to be solved first: the current menus are statically generated and they are recreated depending on the menu context. So it needs a bit more sophisticated merging and registration of extra supplied menu options.

@petar - import/export: Yes, a import/export feature for news bins is really necessary and could also be used for other node types or generally for item sets.

@intangible - synchronizing: This is something I'd like to have to. But do you know a standard synchronizing mechanism every user would be able to handle (and setup) and do you have some storage servers. I fear this will stay a feature of commercial aggregators :-(

@stuffcorpse - sorting, multi-selection: both won't definitively come. Liferea is a simple aggregator (mostly because of the limited development resources, currently only me) and multiple selection is a victim of simplicity. The same for sorting, I don't see it as a major use case. Why can't you sort the feeds yourself right when creating them? How often do you need to sort 100 feeds? I think this is an invalid use case.

idoric said...

Hello, I discovered Liferea recently, thanks for that wonderful and powerful application. it's the only one I found wich is simultaneously :
- free (and compatible with GPL)
- running under Linux
- managing html and enclosure/podcast in one application
- downloading automatically enclosures.

From my previous aggregating application (which was akregator, with amarok for podcasts), I lost one little (1) feature :

the folder is an union of the feeds under it, sothat, when you clic on a folder, you see the union of the items of all the feeds under it. (I hope you will understand what I want to say, sorry for my english, but it's not my mother tongue)

(1)IMHO, it's not a big deal to implement, but perhaps I'm wrong.

Lars said...

@idioric: This optional feature is already implemented but you need to enable it explicitely in the preferences (tab "Folder").

idoric said...

Hô, an optional feature... ok, it works now, thanks :)

Anonymous said...

What I really miss is the ability to set feed properties like update interval and archive settings for all feeds in a folder simultanuously.

Since I monitor my machines via RSS, a exporting and importing a single folder from the feed list would be perfect, that way if I create a new (virtual) machine, I only have to import a standard list of feeds and only rename the hostname. Please refer to: http://wirespeed.xs4all.nl/mediawiki/

Anonymous said...

A feeds-in-error metafolder (similar to Unread/Important) would contain all feeds that did not synchronize correctly or are broken.

intangible said...


Actually, I think the simplest way to implement synchronized feeds is this:

Since you're already going to be implementing a SQLite storage engine for the new version, how about abstract the database calls a bit more so someone can setup their own MySQL database for the storage backend?

Also, Sqlite is multi-user capable if I understand correctly, so make the location of the database file configurable and make sure it's multi-user safe so I can leave my DB file on a file share.

I prefer the MySQL alternate feed storage, but there's no reason you couldn't do both. What do you think?

Lars said...

@anonymous: I definitively don't want to implement multiple selection neither for the feed list nor for the item list. Liferea is per definition (and development resources) a simple aggregator.

As for the "error" search folder. This is a mismatch of the search folder concept. The search folder is used to search items, and presents items: but not feeds. The wish doesn't match the Liferea GUI. And you can easily recognize the problematic feeds by the error icon in the (uncollapsed) feed list.

@intangible: No, I don't plan the extra efforts for a DB abstraction. But everyone is free to join (and extend) the efforts! As for the alternative file I'd say the file path should not be configurable but with a symbolic link you should be able to use a file on a share.

intangible said...


The file on a share would definitely work, as long as liferea is written in such a way to recognize that another instance may be using the same file at the same time.

Lars said...


> [...] as long as liferea is written in such a way to recognize that another instance may be using the same file

Which with network file systems is pretty hard. I know of no application which solved this in a simple and reliable way.

I strongly discourage to use liferea from two hosts at the same time. Although I see the possibility of this in a NIS domain. Currently Liferea does desktop locking using libbacon (which many GNOME applications do use).

liubo said...

Gmail has a good feature is session.It put the mail that one personal send into one,so we can read it very easy.
I hope liferea have a same feature like it,put the same headline into one item.
Because i use liferea to receive the rss items from google's maillist,so there are too same headline itme and there are seperatly.

Lars said...

@liubo: I know which GMail feature you refer to, but Liferea does not support such a item matching feature and I do not plan to implement it.

Anonymous said...

It would be nice to sort feeds by read/unread status first, then by date. This would be similar to the Unread metafolder, but on a per feed basis.

Joshua said...

As you move towards sqlite, import/export will become more important, as sqlite is a bit harder to play with than xml (although certainly not a barrier for someone trying to write a real application). I see you have already put this on the todo, but I just wanted to emphasize.

You might consider providing some simple wrappers to pull data from the commandline. Or just let people know such a patch is welcome :-)

Joshua said...

One thing I'd like to see happen in liferea is for the memory footprint to be reduced.

Since I configure it to poll fairly infrequently (to be nice to httpds everywhere), I generally leave it running so that I can periodically pop it up and see what's going on. Liferea is by modern standards not a very heavy application, but still it is not unusual to have it occupying 35-40 megs of space in my actual ram chips. X0 fewer megs in a semi-permanent fashion is not ideal.

Of course I am a lazy user and have not bothered to investigate which components are eating the memory (I am using gtkhtml). I suspect that much of it is in xml parsers and xml data, gtkhml, and gtk itself.

Some thoughts:

- liferea already does pretty much everything I need, and has for some time. So I value leanness over features if there is a conflict, though of course I'm only one user.
- consider the possibility to somehow reinitialize the fat parts. Whether that's the html renderer or the whole gui, I don't know. giving gtkhml a mmapped memory pool that you toss (along with gtkhtml) every 200 views or something. Or perhaps just enabling the capability to seperate the polling from the interface (mbox for feed readers?)

Lars said...

@joshua: I understand your wish, but believe me half of the other users do want the program to get faster and do not care about the current memory footprint (as long as it doesn't leak).

The current memory footprint of about up to 50MB RAM for 100+ feeds with cache size of 100 items per feed is mostly caused by the use of vfolders (not using them could help as a workaround) which are dynamic search results who force all matched content to stay in memory. All unmatched feed content is loaded from disk when necessary and unloaded as soon as it is not necessary for display anymore.

Because vfolders are constantly modified (each time a feed is updated) they are not unloaded to disk. Anyway loading it from disk when displayed would eat up the same amount of memory.

Of course the whole concept is limited by two facts:
- the decision to load feeds as a whole from an XML file
- large vfolders (e.g. the unread vfolder) mean eating up a lot memory

The alternative would be to sacrifice speed by loading data per-item only (e.g. like mail clients do).

Anyway the introduction of an DB backend will provide new caching possibilities allowing an even better compromise between memory usage and speed. But still even for the DB cache size I would consider maybed 20MB as a good idea.

Please also consider the relation of the data the program processes (with 100 feeds 100 items each usually around 40MB disk space used) and the memory needed to perform it without to much delay. Maybe Liferea has a simple ("not heavy") functionality, but the memory footprint is not necessarily caused by the functional complexity, but by the portions of data processed at the same moment (e.g. when HTML rendering the contents of a vfolder matching 5% of the items of all feeds).