node

I just came across this post: http://drupal.org/node/53836

I agree with the basic points. From an administrative post (and only trying to maintain a small site) I've already wished that I could go to /admin/node and for a group of nodes make all the same common changes (e.g. author, taxonomy, etc).

From what I know about Drupal, it would be simpler to imagine trying to code this if actions could only be applied to nodes of one type.

• Users, comments, taxonomy terms and attachments become nodes
• Why do this:
  • Simplicity, consistency and code reuse
  • Allow us to extend these content types as we do for nodes, without rewriting code
  • Allow relationships between these, without needing a mapping table
  • Why users:
    • Use CCK and taxonomy instead of profile.module
    • Use workflow for user signup/promotion
    • Location module does not need to deal with users separately, just location enable the users node type
    • Users birthdate can just be an event field. Birthdays are just repeating events
  • Why comments:
    • Use workflow to moderate comments
    • Use taxonomy to classify comments
    • Use relationships for threading
  • Why taxonomy:
    • The taxonomy builder becomes a streamlined interface to both build a tree of terms (nodes) and select an item from that tree to classify a node
    • Both the tree and each classification can be designated using relationships
    • All the taxonomy storage and retrieval functions can be encapsulated by the relationship API
  • Why attachments:
    • Less confusion about when to attach media directly to a node and when to add it using a media module node
    • The current attachment interface could then be a quick and easy UI to view/add/update attachments - uploading and adding attachment nodes, and relationships to those nodes (from the original node) on the fly. Expanding title/description fields that update the attached node could also be provided
    • A unified view of all attachments, whether they are added using the standard attachments control, or a more sophisticated media module
    • Potential to write generic gallery modules that don't need to understand different media module node types
• Each of these already has a well defined APIs, meaning that changing the backend storage to nodes should not be overly hard
• Existing API code would generally move to node hooks, and the old API functions would just become wrappers
• Modules that are directly accessing affected tables (most commonly the users table) will be broken by this change, but if their own uid columns are updated things should still work fine, as user metadata would still be stored in the users table as it is now (the only duplication of data might be user name - stored in both the node title and the user table)
• What will be significantly harder will be to upgrade existing sites, as all the id's will change.
  It should be possible to use some mapping to work around this:
  • Find the highest 'old-style' id in existence.
  • Ensure that the next nid is higher than this (bump it up if it is not). This value becomes the threshold.
  • Create nodes for each object, adding their old and new id's to a mapping table.
  • Update all fields in existing tables to use the new id's for each object (this could also be done automatically for contrib module tables, assuming that uid fields are for users etc).
  • When a request is made for an id below the threshold, map it transparently to the new id. This could be done at the function level for greater compatability, or (more simply) at the URL aliasing level.
  • This functionality could be wrapped in a module, which could be disabled for new sites as it is not needed.
• Potential DEP Dependencies:
  • Relationship API. A lot of the benefits/simplicity of taxonomy and comments becoming nodes comes from the ability of relationships to provide a standardised way to store the node-relation metadata.