[[ Notes on Liferea, its development and cool new features... ]]

For support please use #liferea at freenode.net or the SF project page!

Sunday, May 18, 2008

Google Reader Sync Support: a progress report

Hello folks, this is Arnold here. Lars had posted about my Summer of Code project: Google Reader Integration with Liferea.

The project got mentioned recently in a Free Software Magazine column (The 2008 Google Summer of Code: 21 Projects I'm Excited About), that also got slashdotted.

Anyway, a lot of work has been done, and it is (seemingly!) pretty much usable. So here is a progress report.

Installation and migration issues



Installation. Checkout the latest subversion repositories, and build it. Now in the left panel, right click, and choose New->Source, and choose Google Source. Give your email ID (which can also be non-gmail google IDs) and password. And you're set. You should see your feedlist on the leftpanel. You will observe the the "Read/Unread" status of all your items should be preserved from Google Reader.

A few notes about migration. If you have a Google Source from a previous installation, it will automatically be converted to a synchronized Google Source. So beware if you don't want Liferea to automatically modify your Google Reader data. You might also notice that some of the "Read/Unread" statuses before migrating have changed, this is because the synchronized Google Source gives preference to the "Read/Unread" statuses from Google Reader.

What works



Lets say you have been using the Google Reader online (For clarity, by Google Reader I will be referring to the online Google Reader API and/or interfaces. I will use the term Google Source for the Google functionality within Liferea). Now, on adding the Google Source, the first thing you will notice is that the "Read/Unread" statuses are retrieved from Google.

Liferea will synchronize subscription lists, and "Read/Unread" statuses both to, and from, Google Reader. This is the main functionality. If you are offline when a local change is made, it will propagate the changes to Google Reader later, when you get connected.

Another cool feature that you will notice is the "broadcast-friends" node. You can now read all the posts that are shared by your Google Reader friends from within Liferea. Although, as of right now, this doesn't show the name of the person who shared it.

What does not work, or does not work correctly



Comments do not work. This is an inherent issue with using Google Reader as a source: if you have been using Google Reader, you would have noticed that Google Reader does not show you a list of comments to an item, while Liferea can (for most feeds which support it). Liferea relies on some information in the feed, which the Google Reader API discards. Until Google makes changes to their API, we really can't do much about it.

Labels. Or Folders. All the posts within Google Source in Liferea, will fall in the same folder. Google Reader categorizes feeds by labels, which can be used to produce a hierarchical folder structure. I will definitely be implementing this over the summer.

Stars, and the "Important" flag. Liferea can flag an item as "Important", and Google Reader can mark an item as "starred". Eventually, I would like to synchronize these two.

Sharing. While you can see posts shared by others, you cannot share an item from within Liferea.

Efficient Updating


In my SoC abstract, I proposed that we can use Google Reader to save the user's bandwidth while updating. Here is the idea I had in mind:

Normally a user can have hundreds of feeds in his feedlist. Whenever Liferea does an update, it has to update each one of these, even if usually only one or two of them have changed. This wastes both time and bandwidth. Using Google Reader API, however, it is possible for us to download only the "reading-list" -- the reading list over all subscriptions -- in one HTTP request. In some sense I'm downloading all the changes to all my feeds in one go. I can use this to recover the "Read/Unread" flags: for any item in the reading-list, the item is marked as Unread. Any unread item under the Google Source, which does not appear in the reading-list, is marked as read.

However, as simple and clean as this might sound, this is flawed: say, while you are at office, you receive some new posts in the Google Reader webapp. You then read it, and so those items are marked as read. Now once you are back at home, you do an update on liferea: this new post will not appear in the "reading-list", so Liferea will never come to know that this post ever existed. You might say its not a cause for concern, since you have already read that post -- but maybe you want that post for offline reading.

So ideally, instead of requesting the "reading-list", I would like to request a list of "Changes since so-and-so date." Unfortunately, the Google Reader API has no such feature as far as I, and the pyrfeed Google Reader API page knows. I am keen on getting feedback and suggestions regarding this, since I would love to have this feature myself!

Feedback, Suggestions and About Me



For a good part of the IST-day, you can catch me on #liferea by the nick arnstein. You can also mail me at arnstein87 AT gmail DOT com.

I have just completed my undergraduate studies from Chennai Mathematical Institute, and will be joining University of Pennsylvania for a PhD in Computer Science this fall. I blog here.

Monday, May 05, 2008

New Subscription Options in 1.5.3

Release 1.5.3 will introduce new subscription options that might help with some minor use cases where you want to modify the Liferea default behaviour for certain subscriptions:

Saturday, May 03, 2008

Full Google Reader Sync Support

With the currently ongoing Google Summer of Code 2008, Arnold Noronha is implementing full Google Reader synchronization support in Liferea! He's already started coding and SVN trunk already provides item download via Google Reader, while previously there was only Google Reader to Liferea feed list synchronization. So everyone who ever asked for that feature have a look at the Liferea again in two months after the Google Summer of Code 2008 application is over!

Sunday, March 16, 2008

Advanced Searching

Over time many users asked to be able to make more complex searches using the search box (e.g. matching multiple terms or doing exclusive matches...). The new unstable release 1.5.1 introduces an "Advanced..." button in the standard search dialog. When you click this button the dialog will change and a dialog very similar to the search folder properties dialog will appear. Here you can define one or matching search rules to realize much more complex queries. This advanced search functionality thereby should now cover a lot more use cases.

Note: Liferea still does not allow you to search only the current feed or all feeds of a given folder. The current DB schema doesn't allow building views with such filters. But given time this might be improved...

Wednesday, March 12, 2008

Liferea + Firefox + Ubuntu

Recently quite a few Ubuntu users had troubles getting feed subscription with Firefox to work. In all cases it turned out that the Ubuntu package firefox-gnome-support was missing. So if you are using Ubuntu and Firefox please check if you this package installed!

Saturday, March 01, 2008

Favicons and Hosted Blogging

When looking at your subscription list you might notice that many feeds have the same icon. For example a white-on-orange "B" for Blogger, a blue pencil for LiveJournal, a flame icon for FeedBurner and propably others...

If you visit the website of the respective feeds your browser will usually present a different icon in the URL bar. Now one might ask why cannot Liferea use the same one.

The problem is that there are two ways of retrieving these icons.

  1. Relatively to the URL of the website (e.g. as "<webserver>/favicon.ico")
  2. A specific icon file linked in each HTML documented served.
Of course just placing a "favicon.ico" file in the root directory of the webpage is the easiest way to provide a favicon. But this doesn't work anymore with hosted blogging (as provided by Blogger, LiveJournal and many others) or feed caching (as used by FeedBurner and many others). The hosted blogging solutions just do not allow you to put an "favicon.ico" file anywhere (thereby breaking discovery variant #1) and the feed cachers usually work with URL redirection to serve the cached feed content (and thereby breaking discovery variant #2).

So what should I do to help the feed reader to find my favicon?

Solution for hosted blogging: You cannot rely on a "favicon.ico" file so to replace your providers icon you have to upload an favicon image (with arbitrary name) and add a link to it directly into you HTML template. The link needs to be placed under the <head> tag and could look like this:

<link rel="shortcut icon" type="image/png" href="http://myhoster.com/content?blogId=4396446&fileId=4387343">

Note: that Liferea relies on the MIME type and will refuse all images without specified MIME type.

Solution for feed caching: You can either use the "shortcut icon" link mechanism described above or you use Atom feeds you can also specify the original "favicon.ico" file there. For RSS feeds you must fallback to specifying the icon link in the website HTML.

If you think there are better solutions please let me hear about it in the comments!

Thursday, February 28, 2008

Attention Profile

Liferea is a news aggregator and each day allows its users to read maybe hundreds of new blog posts, news articles or podcasts. Many of those are tagged by their authors by descriptive categories. So if it know what the user likes to read most why cannot it preselect those favourite "type" of articles?

The new 1.5 code now keeps track of the absolute number of read categories. Under the "Tools" menu you can now find a new option "Attention Profile" to view the per-category count.


While this might not yet be very useful, this statistic keeping opens up the possibility for more sophisticated features. For example search folders for your most favourite categories, feed and item rating, APML exporting...

Be warned this is experimental, it might work out, it might not. It might hurt performance, or not. Also it arises ethical questions about creating user profiles. All things that still need to be thought about.