RSS design goals

Suggestions are most welcome, in particular pointers to how to do things the 'Right Way' with regards to RSS.

Library features

Handle the great majority of available feeds

In practice this means directly supporting RSS 0.91, 1.0 and 2.0, with passable support for the in-between 0.9x's.

It also means that if new formats like Atom become sufficiently popular then we shall add support for them too.

Compliant HTTP behaviour

1.1 support is the obvious target (currently lacking some of the mandatory encodings)

Support for If-Modified-Since and ETags to make conditional requests and avoid burdening servers kindly serving feeds

Do the Right Thing with 301 Moved Permanently responses and rewrite the stored feed information.

Polite fetching behaviour

Honouring the suggested fetch times, using If-Modified-Since or ETags to conditionally request, rewrite moved links and support conditional requests (as described above)

Edit sources

Drag & drop supporting view that can be used to add, remove and categorise sources. Can move items by dragging them.

Store sources on disk as bookmarks with extra attributes for the title, when the feed was last fetched, categories, icons &c.

Store with the source a list of item identifiers that are marked as important or read with their published dates (to allow purging of old items)

Applications

Just one client to begin with:

DeskFeed

Deskbar icon

Showing the current state of the feeds (perhaps a graphic representation of how 'hot' things are, plus counts of the new/unread/important items)

A tooltip showing the former more verbosely

Context menu

Click on the deskbar icon to get a nested-categorised list of feeds with their items. Counts for 'fresh' messages bubbled up to the parent's menu item.

Pending user-testing, menu text scaled to how busy the sub-menus have been.

Only split categories into sub-menus when there are more than one.

Sub-menu for item/source to display how old the piece is, and allow refreshing of the feed.

Must show the progress of fetching and make it clear when a feed is broken and be helpful about filing a bug report (with us or the feed-owner).

Edit sources

Invoking core library's view.

Keyboard navigation

To allow walking the menus and launching items/sources.

Not doing

Things that aren't going in (unless someone makes a compelling argument for them):

View source

Not that interesting for a user-facing app

Open questions

Things we are deferring to later or possibly never:

Parse-at-all-costs?

Notion proposed by Mark Dive

Pros

Works well in a tag-soup world

Cons

Encourages content authors to make a tag-soup world

We'll have to live in the world around us, so breaking gently could be useful. Long term this may mean carrying two parsers around. For the time being we'll support well-built feeds and get the basic parser up to scratch and have a place to file feeds that don't work with our parser (whichever party is at fault) and then find the most effective way to make those work. Often that may mean simply aiding the publisher.

The other way to do this is to add an on-fail-cleanup step, that then leaves the core parser alone.

Smart search

With find-as-you-type text searching in all fields plus attribute-structured search.

Likely implement by making the search view from videdot more general and having a Tracker-style-query-with-context view.

Caching of feeds to disk

Very helpful for an offline-reader, but not a compelling prospect for my uses. It could go in the core library if it were really desirable, but would have to be accompanied by cache-clearance handling, which would be significant effort to get right.

Direct support for caches and proxies

Although'transparent' proxies will work as well as they ever do.

Three-paned reader

Using the same underlying library. The most prevalent type of RSS reader for other platforms. Will only write it if there is much call for it.

Complications include embedding a layout component that can show an item's description, making sure that is done in a 'safe' way, fathoming the intent of the author as to whether or not the description element contained markup (which may not match well with what the specification said was allowed).