[development] object.module - part 3

[Edgar Whipple]

[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]