Funnily enough, my recent post about wishes for Drupal happened just before discussion started afresh on the recurring "everything-as-a-node" theme, in which I seem to have been played the re-animator part this time.
Thinking deeper upon this issue, I figured it would be interesting to see where Drupal stands currently (in D5) regarding the reularity and orthogonality of the hook system and most visible content-related entities: nodes, comments, terms, vocabularies, and node types.
The resulting table is attached to this post (OpenDocument format), and shows some interesting results:
- from CRUD events, Create/Update/Delete have hooks for most content entities, while Retrieve is only hooked for nodes, while retrieval functions for other types are not hooked.
- the hook system for nodes is overdeveloped when compared with other entites
- there is not always a clear-cut distinction on the "before/during/after" sequence of events in the existing API documentation : developers have to rely on code reading,
It certainly looks like unification could indeed bear fruit, in terms of simplifying the API for contrib developers and possibly even make core simpler, but this might well be along the "everything except nodes is an evolved CRUD entity, and nodes are this, plus something else" than along the usual "everything is a node" original line.
The other tentative conclusion is that we contrib coders would certainly benefit from having a system in which hook sequences in high-level events like an insert are actually specified, clearly defining the "before vs after" role of the hooks and removing the "during" role.
Of course, I don't work a lot on core, rather with it for contrib modules, so this table almost certainly contains errors and maybe missing hooks in the first version attached to this post. If it is found to be of interest to other devs, it can obviously be turned into a handbook page once it is corrected (I've placed it under CC BY 2.0 so Drupal.org can use it without problem).
So, without further ado, fire up your spreadsheet, and look at that table.
2007-01-23: update. Page is now on d.o. as node 112180, awaiting publishing and "full HTML" filter to display properly as a table.
Usability and abstraction are at odds
The Chandler case is not one of abstraction
Funny: I had just read that post earlier yesterday, and I happen to have followed the Chandler case with some interest. Their problem, as Joel Spolsky describes it about the book, does not seem to have been about abstraction but more about committee decisions versus coding, much like the ISO OSI protocol suite versus TCP/IP.
I think the point you're making about usability is the part that Joel criticizes the fact that Chandler tried to merge appointments and mail, and makes fun of it as though it was nonsensical. However, IMHO this is the weak point of that post : GroupWise has been designed that way since its Wordperfect Office days, and it happens to work quite well as a model, both for programming with it and for end users.