[Continued from part 3] I said a previous followup that I think we really can make everything a node. I wanted to add a bit about why I think so, and about what some of the implications of my pre-roadmap concept might be. However, I covered in a separate post much of what I had in mind, under the subject "Everything's a node != Everything's in 1 table". So instead, I'll talk here about the effect my ideas might have on module-level developers. (Some of this isn't entirely consistent with my previous posts. Please excuse that; I'm thinking out loud here.) I mentioned that I think there should be a unified API for handling all node types, which includes all the "metatypes": content nodes, taxonomy vocabularies and terms, users, and all the rest. The example of various modules proves that any of those "non-content" types can in fact represent content. Therefore, they should be nodifiable. But, I don't think module developers should be forced into thinking of all different node types in identical conceptual terms, and I certainly don't think the users should have to deal with it. So, here's an idea on how to avoid that. As I mentioned elswhere, for $node_type = 'mynodetype', these two function calls have the same meaning: node_create($node_type, $field_values_associative_array); mynodetype_create($field_values_associative_array); So, define default CRUD handlers that everyone can use, and declare them automatically for every new node type component. (The possibilities of _how_ are several, so I won't go into that here.) By simply, say, adding a line to my_module.info like: module_type = MODULE_NODE_TYPECOMPONENT I get a full set of default handlers with *my own* module's name on the functions. That means developers can think in terms of taxonomy_term_create() and custom_contenttype_delete(), without having to think much about how they're implemented using the same API's and the same storage engine. Then, perhaps by adding a couple more lines: api_overrides = API_NODE_DELETE, API_NODE_VALIDATE api_extras = myfunctionname, myotherfunctionname all sorts of possibilities open up. The developers can introduce whatever high-level functions they need, in a standardized and robust way, and without complicating low-level data handling any more than the absolute miminum necessary. CONCLUSION My point is that nodifying everything, with all the benefits that go with that, doesn't need to make Drupal any harder for ordinary developers to wrap their brains around. We could, in fact, make it easier, *if* we are sufficiently willing to distill truly flexible, powerful back-end API's and their implementation. In Part 3, I mentioned an idea for a new module installation model. I'll describe that idea further in my next and final followup. This, however, concludes my basic proposal. -Edgar Whipple drupaladmin@misterwhipple.com www.misterwhipple.com/drupal5 as soon as I copy the data to my hosting account.