[development] object.module (was nodify.module idea: 'everything is a node')

[Edgar Whipple]

Nedjo Rogers wrote:
> 1. Write a generic object.inc or object.module. Maybe this has two
> tables of its own:
[...]
> Every object is now uniquely identified not by a single id but by two:
> the object id and the object type id. Modules can register their own
> custom object_types. Possibly other core drupal objects also register:
> files, roles.
This has an implication that may not be your intention. In my
experience, compound primary keys can be a real bear for subsequent
programmers. It obfuscates the table relationships, and can make a field
look like a key when it isn't. Perhaps it would be better to guarantee
that every object's id will be unique, regardless of type. Aesthetics
aside, this would also leave the door open for node type transformations.

This quibble notwithstanding, it seems an excellent approach.
> INSERT INTO {object_type} (
>  values (1, 'node'), (2, 'user'), (3, 'comment'), (4, 'vocabulary'),
> (5, 'term')
> )
> 2. Having reworked our existing object handling to extend a base
> object, we then look one by one at the systems currently specific to
> nodes and consider attaching them to the base object instead, so that
> they still apply to nodes but are also applicable to other object types
An important point: in the current system, all of these data types can
overlap. Users can be nodes using nodeuser; anything can be a vocabulary
or a term with the category module. I think this is a good thing, and
that the primary reason many people dislike the overlap is that it can't
be done very cleanly at present. For this reason, and for the sake of
CCK-style type inheritance, I think we need another layer between your
'object' and the entities named 'user', 'comment', 'term', etc. I'll
explain in a separate followup.
> .E.g.: Does this sound right? Doable? For 6.0?
I wasn't around for the 5.0 effort. Is it OK that this will pretty much
break every existing module? Or, on the other hand, would it be feasible
for a legacy-support layer to provide API translation?

-Edgar
So, what are the basic