[development] Module Installation idea, was Re: object.module - part 5

[Edgar Whipple]

I mentioned in previous followups that I had an idea about a method for
installing modules, and that I think it has potential to improve both
install time and bootstrap time, and perhaps robustness as well.

Well, it turns out the idea is simpler than I thought, and perhaps
slightly less exciting therefore. So, here's a little more detail here
about my core idea.

But not a lot.

MODULE STORAGE SETUP

  The simple idea is that, ideally speaking, no module should ever set
up its own storage in the database. Instead, let every module do any or
all of the following.

1) Define new field types, implementing validation and widget handlers,
specifying underlying database primitive types (but no more than that),
etc.

2) Define a new node-type component using existing field-type
declarations, optionally defining non-default CRUD handlers, and *very*
optionally defining higher-level API functions.

(We could even set up default handlers for some of the
more-common-but-not-universal additions, to encourage consistency in
names and semantics. For example, more than a couple modules do "set a
relation of my custome type X between nodes Y and Z". Perhaps we could
define generic, hook-slash-callback implemented API's for that sort of
thing.)

3) Declare one or more new node types, using only an identifier and a
list of already-defined node-component types.

...and let the core API functions handle the specifics for setting it
all up in the database. Of course the developer will still implement his
callbacks and such (duh, right?); he's just not allowed to touch the
node-data and other tables in the database.

  I've dug into the guts of about a dozen modules so far. [I know; it's
not much. Just give me time. :-) ] And so far, best I can tell, none of
them will need direct access if the new core functions along the lines I
have described.

  Making these feasible and then enforcing them could prevent all sorts
of database awfulness, starting with namespace collisions. It would also
make it easier for developers to discern what they really need to add,
and what they don't.

I have more in mind, but I'll stop there. 

-Edgar