Notices

That's exactly what I don't want. I have over 1000 feeds in google reader and I would want to be able to choose what alerts I get rather than see everything in real time. As if I don't already have an issue with ADD! Ideally we need an IMAP like solution for feed reading (newsgator offers something close, but is closed) and GR still only works with itself.

The main feed reader applet would be great if it picked up and was synced (read status) of my feeds from Google. That way you'd get a relatively non-invasive way to see the current stuff and an easy way to click through and read what mattered in realtime.

Syncing is indeed important.

Managing properly thousands of feeds is a complex exercise that is probably out of scope for a desktop plugin and perhaps even to a whole mobile device. I would be happy if our preferred feed reader would handle efficiently the newbie case (discovering the potential of feeds) and the vast majority of users handling no more than 50 feeds (although some of them can be really noisy).

Still, imagine I could use tags to filter/promote entries to the desktop plugins e.g don't push entries with "Paris Hilton" or make sticky entries with "Maemo".

I also like Jaiku's principle of making easy to subscribe to a whole bunch of stuff and then be selective when unsubscribing (for instance unsubscribe to last.fm feed from my dearest colleagues).

quim,

jaiku is a special case for the feeds, they are on the site itself, we would need interaction with a web browser for arbitrary feeds, which whilst not a major deal would require coordination.

As for handling multiple feeds concurrently, maybe find/create a webservice the kind of subscription/easy interaction model you desire and then simply point the tablet widget/app and desktop app towards your account (much like mauku does).

Isn't all this the kind of thing mauku itself has highlighted for future though?
I have seen Henrik mention building an expanded engine for alternative services.
http://hhedberg.jaiku.com/presence/50028539

What's the relationship between local/online in a device that can be always online?You want video and audio downloaded only when wifi is around so you can enjoy them even if you are offline. Almost the same with pictures.

Microblogging is not a problem, although it would be nice to have a Save Links option when microblogs point to full pagess and/with media.

The advantage of a desktop plugin is the possibility to push the feeds and put the latest automatically in front of me. This is what Mauku does well. My device is almost never in my pocket. When I'm not doing anything with I leave it on the table and look at it when Mauku wakes up the screen.

I want:
A "Preview button" that allows you to view actual article in a frame. Clicking again on that button goes back to RSS view.

Here are some advantages:

- You can see and post comments right from app.
- You can read truncated rss feeds entirely.
- You don't lose time opening a new window or tab in order to go on the website and see the article in its original context.

Preview can be opened by clicking on article's title, preview button, or typing Shift-V

for more details...

Syncing is very important. Most people have at least a computer, a NIT, and some kind of phone (sometimes also with this function).

I have RSS feeds in screen on a server. I have RSS feeds in Opera on my laptop. I could get RSS feeds on my tablet and phone, but I bet this would make me lunatic. Because some already overlap.

If you have IMAP, it is synced. PIM (or equiv), sync is important. Bookmarks? OK, point there, but back in the days Netscape had LDAP support for this purpose. IMO this is important for RSS as well. You can have the same RSS feed on several devices, but what kind of use is it to know that some are unread when this isn't synchronized between devices? This is not a NIT problem, just a generic problem.

Another problem of RSS is signal-to-noise. Some websites solve this by using categories and allowing the user to sign up on specific categories. Or, they allow the user to specify the categories they're interested in in their profile hence they have a personalized start page. But then there is this issue of too many RSS feeds. So it has to be intelligently sorted. This isn't easy. And that is why RSS is not something to use without serious hacking on the data. I subscribe to a newsletter of a website instead of their RSS feed and get daily the news on a specific time in a nice HTML-free (chosen by me) e-mail.

A simple example of hacking the data: ignoring based on keywords in title or body. In an IM client, e-mail client, or IRC client you can do this. In an RSS reader you can't.

Personally, it would be nice if the RSS reader were a browser-based app, that used locally run AJAX to sync and manage feed reading right from the device. You'd get fewer additional apps to need to be used, instant browser integration, and no need to sync because you'd already be in a browser (and one of those settings would be to sync with 'x' RSS account or RSS site(s)).

Of course, do so such things would mean that the JS performance of microB (or whatever the next browser for the IT would be) would have to be much improved.

After that, I would assume that developing a widget would be just a matter of some Python play, since the data would already be there to be gleaned from the browser.

dkwatts and ARJWright go in the direction of a browser add-on. There are some candidates in the Firefox arena. This would be an interesting path since we have a Mozilla based browser and the Mozilla guys seem to be targeting most mobile platforms (including S60). Perhaps that code running on Maemo 5 could be quite cross-platform?

allameswereout, syncing with an online service of your choice might be the easiest path? You could have all your devices syncing there, instead of trying to make them sync between them without Internet.

The obvious solution: you have a server get all the RSS feeds, perform any filtering required, and redistribute them to clients with some protocol. And there's no standard for that protocol yet...

My suggestion: AFAICS, IMAP is quite suitable as the redistribution protocol. Obviously, a good email program is not necessarily a good feed-reader, but the protocol can be the same, and mail-centric clients will still work in a pinch. Thoughts? (Am I missing something this protocol needs that IMAP doesn't support?)

1) Grab RSS from various selected feeds every X minutes
2) Apply blacklist or whitelist filters on feeds (which?)
3a) Export the filtered RSS (or combine them) and host them (for example on Ovi) as RSS (or, instead of RSS, possibly as HTML + e.g. JS on say Ovi)
3b) Keep track of previous send and e-mail each item seperate (seperate account from main account in case of POP3, or e-mail client & server supports IMAP). Or even SMS them for a small fee (some services for this already exist).
3c) Same as 3a, with or without blacklist but with high priority whitelist. If whitelist matches, e-mail (or SMS) the item instead of RSS because we're positive the user is very interested in this item.