On Wed, 2006-05-10 at 13:28 -0400, James Walker wrote:
On 10-May-06, at 12:50 PM, Dries Buytaert wrote:
On 10 May 2006, at 18:44, Boris Mann wrote:
Please make patches against core, since this will help everyone long term, rather than just those who build/maintain an alternate file handling structure.
I second that. Core's file handling, both the file API and the upload.module need love.
They do, and I have been trying to fight hard for things like audio.module stay the course with the core API and work to improve that rather than everyone doing their own thing (as I have done for image as well).
File/Media handling is (as far as I'm concerned) a major hot button to be addressed in the next release, and I intend to start "rallying the troops" in the near future and putting patches where our mouths are.
Those who have thoughts on the issue and haven't already (and there's already some great stuff) have a look through http:// groups.drupal.org/file-api.
So do we want to do the iterative cycle on the existing file.inc and upload.module, or throw in something new. ------------------------------------------------------------------------ I have a good chunk of a new file handling api already written. You can see it in cvs. http://cvs.drupal.org/viewcvs/drupal/contributions/modules/filesystem/ some elements are only sketched in at the moment, but they are at least linted, but maybe what is there serves to express my idea. I wanted to write tests for all of the api functions first to exercise them as I develop the lower level abstraction layers. I still need to research how name spaces are handled in filemanager since people seem to have a high opinion of the module in general. -------------------------------------------------------------------------- While I like my ideas, It would probably be better to massage file.inc and upload.module into the shape that is needed so we create the upgrade path as we go. So here is one potential battle plan. 1) The first thing I'd like to do is relate files to uid instead of nid in the {files} table as it simplifies a lot of the preview code which is pretty hairy. I need to write a file browser in the process. So users can delete old files, or unintentional uploads. I can handle the upgrade path and the file.inc and upload.inc changes. I'll struggle with the UI for the file browser though. The initial database migration path is something along the lines of --create table node_files select nid, fid from files'; --alter table files add column uid --update table files join node on files.nid = node.nid set files.uid = node.uid; --alter table files drop column nid Then all of our add file widgets are just a common mini-file browser. plus a single upload field. 2) Then an inclusion of a hook_file($op) in all of the file_* functions that act on files. (this will give us the life cycle hooks to do advanced media handling, create derivatives, modify files, alter output ex) render a flash player or quicktime player, but that can also be done through theme functions currenlty. You can already do some fancy stuff through nodeapi with module weights by making your derivative generating module heavier than upload.module, but it's clunky.) ------------------------------------------------------------------------- Those two account for my biggest desires for 4.8. The rest of it is just pudding. although splitting/improving private files is just off the list but sits in a big pile of file / access control issues I haven't really thought about alot. ------------------------------------------------------------------------- I'd rather not take the time to write and test these patches without some sort of a 'this direction is good' from the rest of the world...