Jeff Eaton wrote:
Here's my highly opinionated contribution to the discussion.
1) All downloadable files should be nodes. 2) Whether upload.module, file.module, or hooha.module does this is a side issue as long as ONE centralized module does it. 3) Attaching a file to another node should involve: a) selecting an exsting file node, or b) uploading a file during node edit/create, which would be saved as a dedicated file node. 4) Inlining an image or a link to a file should be done using tokens.
Yes, yes and yes to all the above. As I think about it more: I see a centralized module that represents a generic/default "file" node, with the concept of 'named' parts. New node types can be added by extending it, implementing hooks for part-type definition, special node creation processing, normal node display, so on. An image node might declare part types called original, thumbnail, resize_1 resize_2 (etc) for instance. Also illustrating this extension mechanism: The default "file" node provides a get_reflink(node,part) that might return a simple <a> link. This is what's executed when a text node references the node in-line or as an attachment. Now the node-type extensions could override that to return some other specific html representation of the file. An <img> for a thumbnail, or a filetype icon, etc. It seems like this node-type framework could be done very cleanly and simply, following the Drupal Way, and would go a long way to satisfying essential file/image needs, while leaving room (and providing opportunity) for more complex functionality in external modules, such as bulk uploaders, galleries, etc. Sebastian