The current TB feed code
The FeedParser object is defined in feed-parser.js and handles converting an XML document for a rss/atom feed into an array of items (aka entries) for that feed. It returns these in an array to anyone who calls
parseFeed, its main public method.
The Feed object is defined in Feed.js and roughly corresponds to a particular rss/atom url. This object handles kicking off the download of the feed, getting a FeedParser to parse the result, and then managing the storage of these items.
The FeedItem object is defined in FeedItem.js and roughly correspondes to a single item or entry for the the feed. A FeedItem contains the internal logic necessary to store the feed in an msf file, to allow the normal mail account/db methods to act on feeds like normal messages.
Two additional datastore objects exist in both entry-point scopes. The first, corresponding with feeds.rdf store those feeds that are subscribed to, and a small amount of metadata for those feeds. The second, corresponding to feedItems.rdf, stores metadata for those items in a particular feed that have been downloaded. These object are available via methods defined in utils.js, though logic for writing to these files is scattered through the feed code.
Code that wishes to watch the progress/results of downloading a feed can set a downloadCallback object on a Feed object that will be notified of various events that occur through downloading/parsing.
The nsINewsBlogDownloader code also includes code to handle managing feeds within the account-manager window, and code to handle subscribing to feeds via commandline arguments.
Toolkit feed code
Toolkit feed code has a single entry point, the creation of an nsIFeedProcessor. This object is passed a previously created and started nsIChannel. It then listens to the channel and parses the incoming data.
Results from parsing a feed are returned to an nsIFeedResultListener in the form of an nsIFeedResult.
The most important property of an nsIFeedResult is its
doc property, which is an nsIFeedContainer that can be QI'd to an nsIFeed. This object then contains an nsISimpleEnumerator for its
entries property, which enumerates all items (aka entries) that are part of the feed.
This object corresponds to a single item/entry in the feed.
Switching to toolkit
The parallels between the current TB code and the toolkit code are fairly easy to see. The Feed object contains approximately the same logic performed by nsIFeedProcessor, nsIFeedResult, and nsIFeed. The FeedItem object contains much of the same logic as an nsIFeedEntry.
Mechanics of the replacement
At this point, it seems that trying to weave the toolkit parsing code into the current feed code would result in replacing the vast majority of the code. Feed objects would disappear, as the above mentioned toolkit objects replace nearly all of its functionality. FeedItems would only remain to the extent their logic is needed to create .msf files for feed-items.
Additionally, the datastore objects are planning to be replace with a switch to mozStorage (or another suitable data format). Thus, the only code that would likely remain at the end would be:
- logic to store a feed-item in an msf file (currently in FeedItem.js)
- commandline handling of feed subscriptions
- account-manager management of feed subscriptions
- xul code for feed subscriptions/properties
As a result of the nearly complete replacement involved in this switch, my proposal is to introduce a new set of feed-code, rather than upgrade the existing architecture. mailIFeedService would be an xpcom service which would handle
- kicking off downloads of feeds
- storing feed results in msf files
- adding/removing feeds from subscription lists
- includes managing the data-store
- includes commandline handling
- managing feed settings