There is a horrible line between file.inc and upload.module. File.inc supposed provides hooks like hook_file_download but these get hijacked by upload.module. Also, file.inc does not define or use any database tables (which is great, as using a database for files should remain optional imho), but upload.module does and confusingly names the database table 'files' rather than 'uploads'.
Its important that we make a definite separation between the core file.inc file and the optional upload.module.
-
File.inc should provide hooks and functions for use with files which should not restrict people to having to make a file a node or store any details of a file in the database.
-
Upload.module should provide one particular way of dealing with files, which most people (but not all) would probably want to use.
-
It should be possible to build a custom module to deal with files which can work instead of or alongside upload.module without any conflicts.
Its also important that upload.module isn't allowed to 'hijack' hook_file_download or any other hook. In HEAD today it does hijack it, but my suggested patch ( http://drupal.org/node/59648 ) fixes this.
NOTE: I'm particularly interested in this as I'm currenlty creating an online yearbook website ( http://www.allyearbooks.co.uk/ ). I want to enable upload.module so people can upload files as per normal for stories and pages etc, but for the yearbook entries themselves the file handling has to be a lot cleverer. I'm not storing those file entries in the datbase at all, but with names like 242_blah.jpg where 242 is the nid. But also, I'm storing the file at different resolutions and dimensions etc etc. Without my suggested patch, its impossible to do this alongside upload.module without giving everyone the permission 'view uploaded files' which I don't want to do.
Comments
I think files is an
I think files is an acceptable name for the files table. I'm not sure about handling files w/o the db.
What would be the point of managing files with a CMS if you weren't tracking metadata and additional data about the file. Its seems like ftp would be a better solution. Or a custom save upload function, but the tools to handle files without the DB should be available. You never know when you are going to need to so something in a temp space and replace the original file.
What I've had in mind was a two layer file API for drupal. A set of 'public' functions which provide database/filesystem level actions together, and a set of 'private' functions which do just the file system part.
So we get some nice layering to play with...
my solution to the files table problem is for the file_revisions table to become node_files and use it only to track the relationships between nodes and file, and data specific to that relationship.
In the end upload.module would end up only being responsible for handling those relationships and placing the appropriate file widgets into the node add and edit screens.
on track
in general, i like jakeg's proposal that each module handle own storage and so on. thats certainly the spirit of of our current file API. it isn't file APi's fault that upload is an imperfect user of its API.
one unsolved need though is that we do want a hok to fire upon the "commit" phase when modules can react to new files being added. modules will want to attach metadata and so on. this is how the old media.module worked.
Everything with its own store ack!!!
While letting every module track its own file collection maybe in the spirit of the current fileAPI, I don't think it is in the spirit of Drupal. I would also prefer to have a FileAPI I could leverage for many cases with out having to rewrite large chunks of file handling/db code for every module that want to play with files.
My mos recent concoction splits the filesystem.module I was tinkering with into a filesystem.inc which will implement the system level filehandling, and storage driver abstraction layer, and filesystem.module which provides and API for centralized filemanagement/db synchronization, a hook_filesystem similar to nodeapi.
I will try to commit it once I have finished splitting the two.
I'm also playing with a similar setup for cck/filefield, which will use drivers/handlers manipulate files that are more explicit than a hook. Probably selected according to mime type.