[development] hook_fileapi (file products and download permission)

[Darrel O'Pry]

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...