[Continued from Part 2] Again, for the sake of consistency and reliability, I'd strongly advocate all the basic node types should be defined in the reference-site implementation using a series of calls to the Layer 1, 2, and 3 APIs, and not defined directly in any layer's code. This will help ensure both that the APIs are correctly implemented, and However, for sake of faster installation of basic node types, we might want to create predigested database data to include in the core download, as with Layer 2. For the sake of faster bootstrapping, we might also want to tag a few node types in the database as *preloadable*. Then, extract this information at new-module-install time into a dynamically defined .inc file full of static array() defs, to be used every time Drupal is bootstrapped. I've just realized I'm implicitly proposing a completely new mechanism for creating and installing modules. I think the idea I have in mind is a is a good one, but I'll spare the details for followup part 5. As examples, the current modules that define field types and widgets for CCK are conceptually talking to my Layer 1. The modules that gather fields into meaningful arrangements that can be added on to existing node types, like Case Tracker or Category, talk to Layer 2. The ones that define a complete node type talk to Layer 3, and lower layers only if they need to. Those that call upon another module's specialty API are calling Layer 4. Nobody ever talks directly to Layer 0, and when people talk, they're talking *in* Layer 5. :-> Using this approach, I think we can safely continuing to call our basic object a "node", without losing any flexibility, and without confusing people. We'll be able to say, "Tada! everything really is a node!" without terrorizing either the developers or the database admins. I'll say more about that in the next followup. [Continued in Part 4]