Maybe I should weigh in on the RDF debate currently going on in Mozilla-land. Aparently there have been plans to remove RDF support for some time. What you didn't hear about it? Of course, you didn't. I sure didn't. Finding that out requires that you spend all your time in Mozilla IRC channels. Ah, IRC: the place where ideas go to be discussed, debated, and then left undocumented.
One source of this is perhaps the recent post Brendan on Mozilla 2.0, in which he links to a post by someone trying to retrieve a list of bookmarks and finds the code terribly complex. Brendan then incorrectly ascribes the problem to RDF. While it's true that the code is complex, the actual problem is caused by XPCOM.
Here's an example of a quite common code pattern found thousands of times in Mozilla code:
var obs = Components.classes["@mozilla.org/observer-service;1"].
getService(Components.interfaces.nsIObserverService);
obs.notifyObservers(null, "browser-window-before-show", "");
Here is how to write that same code in a more sane environment:
ObserverService.notifyObservers(null, "browser-window-before-show", "");
That removes two lines of code from the referenced getBookmarkList function. Several more lines can be removed by having the RDF objects implement nsIClassInfo or some such so one doesn't have to call QueryInterface all the time (more XPCOM overhead).
But what's really interesting, at least in this particular case, is how to access the list of bookmarks using Places, which is destined to replace the RDF bookmarks implementation. Based on the documentation, I wrote a version of getBookmarksList using the Places API instead. Look at this:
function getBookmarkList(doSort)
{
var bookmarks = Components.classes["@mozilla.org/browser/nav-bookmarks-service;1"].
getService(Components.interfaces.nsINavBookmarksService),
var history = Components.classes["@mozilla.org/browser/nav-history-service;1"].
getService(Components.interfaces.nsINavHistoryService);
var ioService = Components.classes["@mozilla.org/network/io-service;1"].
getService(Components.interfaces.nsIIOService);
var query = history.getNewQuery();
var options = history.getNewQueryOptions();
options.setGroupingMode(options.GROUP_BY_FOLDER);
query.setFolders([bookmarks.toolbarRoot], 1);
if (doSort)
options.SORT_BY_TITLE_ASCENDING = true;
var result = history.executeQuery(query, options);
var root = result.root;
root.containerOpen = true;
var items = [];
var count = root.childCount;
for (var i = 0; i < count; ++i) {
var node = root.getChild(i);
if (node.name && node.url) {
var iuri = ioService.newURI(node.uri, "" , null);
bookmarks.getKeywordForURI(iuri);
items.push({ name: node.name, url: node.url, kw: iuri});
}
}
return items;
}
Now, I don't know about you, and maybe I missed the secret getAllBookmarks function somewhere, but that sure doesn't look all that simpler to me. In fact, once the XPCOM overhead is removed, retrieving the list of bookmarks using the newer Places API appears to require even more code than the equivalent code using the RDF API does. Go figure. Maybe it was just a really bad example. And that doesn't even consider changing the RDF API, which admittedly isn't spectacular by any means.
Maybe instead of focusing so much energy on RDF, which isn't particularly broken, we should instead focus on cleaning up things which are. Like removing all the XPCOM overhead, or why there are fifteen interfaces to desribe a window. Me, I'm working on making the clipboard and drag and drop APIs easier to use. Instead of writing twenty lines of code to indicate you want to drag something, you'll be able to use the WHATWG Drag and Drop API and just write two.
