[development] The future of hook_node_info()

[Daniel F. Kudwien]

> 1) ... That needs to 
> get ripped out and made pluggable per-type, and stackable.  

There is an initial idea/approach and patch that needs architectural review:

http://drupal.org/node/441148


> 2) Easy programmatic creation of new nodes.  Some modules 
> need to have custom behavior that comes with their nodes.  
> Poll is a text-book example.

Also note that Poll could as well provide a field only, as someone suggested
in

http://drupal.org/node/61285


I'd like to add:

3) Make Node API re-usable (like Cache API)

There are many, many, many modules in contrib that could and would very
happily use "nodes" as storage type and for processing (i.e. load,
load_multiple, view, edit, insert, update, delete, *_multiple, + being
fieldable).  But they can't, because we still have a lot of magic happening
around nodes:

- Nodes appear on admin/content/node
- Nodes appear in search results
- Nodes appear on node/add
- Aforementioned default access permissions
- Possibly more.

What we currently call and understand as "node" is clearly a node of the
type "content" in reality.

Also, considering modules for private messaging or automated feed imports
that could (re-)use Node API, {node} would quickly become a bloat of
container for everything.

So lately, I was wondering whether we could open the door to allow modules
to use the (proven) Node API design by "classifying" nodes and making its
storage re-usable, _exactly_ like we do it with cache tables already.

All cache tables share the same schema, and we can do:

cache_get('cache_form')

Considering classified nodes, a module could do:

node_load($nid, 'message');

Thoughts?

sun