View source for Thunderbird:Thoughts on Removing RDF

We use RDF for the following:

*1. Going from a folder URI to an nsIMsgFolder, i.e., nsIRDFService::GetResource
*2. Populating the folder pane, including the folder views like favorites or MRU
*3. Populating the address book list
*4. Populating the various menus and widgets that contain folders or address books.
*5. Rewrite the RSS code not to use RDF as a persistent data store.
*6. Miscellaneous things (like ispdata.rdf, and stuff I'm forgetting).

Replacing nsIRDFService::GetResource  should be pretty straightforward. We just need a service that can go from a folder URI to the corresponding nsIMsgFolder, or a new method on an existing service, like nsIMsgAccountManager. This will touch a lot of code. One subtlety - GetResource will create an resource object of the right type if the object doesn't exist. This behavior might be more trouble than it's worth, since it leads to orphan folder objects with no parent, if called on a URI for which there is no corresponding folder. However, because we lazily create special folders like Sent or Drafts, sometimes we may want URI's for folders that don't exist yet.

Implementing the folder pane without RDF should be straightforward. We'd just need folder views that implement nsITreeView like the existing msg views, i.e., nsMsgDBView and related classes. We'd need to handle invalidation of tree lines directly instead of  notifying rdf that a resource changed and having it redraw the folder pane.

Implementing the address book pane would be similar. I think we would need to add some object/service that centrally manages address books and directories, however. For folders, the account manager does that, since it keeps track of the server objects, which keep track of all the folder objects. For the address book, we currently go directly from prefs to resources, and let RDF manage the resources.

Populating the menus and widgets w/o rdf is the biggest unknown to me.  If you grep for "datasource" in mailnews/*/*.xul and mail/*/*.xul, you'll see all the ui widgets that are populated using RDF for Thunderbird and Seamonkey. There's some work going on to do non-rdf based xul templates - [[XUL:Template_Features_in_1.9]], but I'm unconvinced that it wouldn't be easier to just populate the menu's in js, and hand-roll some filtering functions to strip out folders/servers that don't make sense (e.g., don't add read-only folders or news servers to the move/copy to menu items).  We'd need to verify that this performs well enough w/ a lot of folders. The account manager UI would need to create the account pane w/o the account manager data source, which is probably a good chunk of work.

Redoing the RSS code not to use RDF  is a bit of an unknown. We'd need a new mechanism to keep track of subscribed feed URI's, and downloaded feed items (maybe we create a new rdf-like service that keeps track of URI's that we can share across components). We'd need to be able to parse the exisiting Feeds.rdf and FeedItems.rdf files for upgrading, though there must be code like this used by other components that had to upgrade from .rdf files.

As far as how I'd tackle this is concerned, I think I'd start with  #4, just because it can be done a la carte,  and I think it's the biggest unknown. It's also one part that *must* be done if gecko gets rid of RDF, in particular, if the XUL Template builder drops rdf support.  I think we could skip #1 and #5 by  just pulling the RDF code into mailnews, if we absolutely had to.  I'd probably do #2 and #3 next, since they're similar to each other.