On Mon, 2006-05-08 at 17:19 -0700, Dave Cohen wrote:
Did my original post make it to both developement and ecommerce mailing lists? (It was supposed to but I only received one copy in my inbox.)
Nedjo, thanks for the reply.
On Monday 08 May 2006 15:45, Nedjo Rogers wrote:
Likley we'd want to keep it as close as possible to existing _api and _access hooks. So, e.g.,
* @param $op * The type of event ('upload', 'download', 'update', 'delete')
might be better as
* @param $op * The type of event ('insert', 'view', 'update', 'delete')
I am fine with that. Not certain the list of ops that apply to files will always be the same as those that apply to nodes, but I can't think of a counterexample now.
copy, move, derive come to mind quickly. Files do have a unique life cycle compared to database content items. I think my most recent thoughts on access control and the file API was to leave that in the 'files as a node' layer. My current thought is that files can exist in three worlds.. 'files as an os level object' for people who want to do file handling as it is now, and avoid the whole drupal thing, but gets you abstracted storage drivers... 'files as cms objects' drupal provides some hooks for lifecycle management and deals with keeping the db data about files straight. 'files as nodes' The top layer of the files universe, provides the node level interface to files, extensive access control, and all the crazy stuff you can leverage node module for, because you want just an end result from combining modules not to write a module. The interactions/priorities of the three layers are still blurry to me in some areas... access control is one of them.
Are you thinking of doing this as a contrib module for 4.7? Part of ecommerce, or a generic file handling module?
I'm thinking of an ecommerce module (maybe ecommerce/contrib, maybe modifying ecommerce/file/file.module) which implements the hooks and allows downloads only when a node has been purchased.
I'd love to see more contrib file handling / API modules appear to encourage some innovation and get peoples ideas into code. A good pool of disparate ideas to juice up a, how dare I use the buzz phrase, 'best of breed solution'.
And modifying audio.module to invoke the hooks as I described in pseudocode.
If there is widespread adoption, upload.module (and probably others) should then emulate audio.module. I'm mostly concerned with the MP3 product I am trying to build. But if I build it using these hooks, I'd like to think they could serve others as well.
-Dave
If you have immediate needs go for it. If you have additional time on your hands you've already found the file-api group :).