There was an IRC discussion about one possible direction for Straw to take with respect to ../LongTermPlanning: to become a general discussion tracker by adding more backends and frontends in addition to the current feed-reading features. The motivation is to integrate all the various technologies and applications to a unified solution for a clearly defined task, which is an improvement of the current offering. Hopefully other GNOME applications in the field would collaborate. (Soylent seems to have a similar motivation in another field, "people browsing", and Telepathy and Empathy in "real time conversations".) If Tracker gains popularity, this might become a more general trend with applications on the ../GnomeDesktop in addition to the web services stuff of OnlineDesktop.
We have to remember that this plan is not implementable overnight, especially where community acceptance and collaboration is needed. We can start right away though, by taking this plan into account in the design of the new storage backend and other architectural changes. Clear separation of the backend and frontend is useful in any case, and if the storage interface is suitable, Tracker when available provides features like indexed text and metadata searches for free.
User interface concept
The discussion tracker would let the user follow new posts and threads of discussion in blog monologues, their comment areas, and between blogs such as aggregated in Planets. This would make Straw a better feed reader.
But to limit to blogs is a purely technical limitation of the feed format, and we would better serve the user by providing tracking of discussions on mailing lists, web forums, news groups etc. In addition to a unified user interface, the integration can help track discussions that are distributed between multiple media or even the enormous social network of the blogosphere.
However, we would at this point leave outside many related tasks, such as general web browsing and real-time discussions like IRC and IM, since they would seem to require vastly different user interfaces and system architecture. This doesn't mean we wouldn't continue to improve integration on a more conventional level too, such as real-time notifications to other apps, and feed subscription from and item opening in web browsers.
Architecture
To avoid the system becoming a mudball of various features implemented in one huge application, there should continue to be modules with clearly defined and narrow interfaces. Instead of current applications, the modules would be visible to the user as various user interfaces and their features. There would be several backend modules for the discussion media, and also several frontend modules for different user interface styles and form factors.
A modular architecture could be based on the blackboard style, where the backends add new items to a central repository, and frontends get notifications of new items, display them and mark them read. Tracker could be used as the blackboard. As it supports RDF, we can use RDF as the common data model of the items on the blackboard.
Whether we use RDF directly or not, a suitable model and vocabulary for the data sharing is SIOC (Semantically Interlinked Online Communities), which has been submitted to W3C (W3C Team Comment). It describes a common model and vocabulary of the following classes and their properties: Community, Container, Forum, Item, Post, Role, Site, Space, Thread, User, Usergroup. News feeds should easily map to this model, as should the current user interface. In addition, SIOC is suitable for other online communities such as mailing lists, message boards, wikis, CMSs etc.
Backends
The backends would implement the polling and other tracking of various discussion resources on the net. They would also perform the conversion of non-SIOC resources to SIOC, before inserting the new items to the blackboard.
Of the current Straw code, backend comprises the poll manager, network IO, and the external feed parser module.
There are modules for several discussion software to make their output include SIOC. Even if these modules aren't widely deployed, some of the code can be used in converters in the system. Some of the modules are naturally deployable on the client side, such as the SWAML mailing list archive converter. Sources that don't co-operate might need to be scraped, just as some sites still don't provide RSS or Atom feeds.
Frontends
The frontends would implement user interfaces for new item notification and item reading. The current frontend is the result of a huge effort and a good start. At first we couldn't expect other GNOME applications to collaborate, but in time they could adopt the architecture and their user interfaces could be used for general discussion tracking too.
The new focus would make a threaded view important. There is at least one desktop viewer for SIOC data, namely Buxon, which happens to be written in PyGTK and implements a simple threaded view.