> 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
