[E-Commerce] [development] hook_fileapi (file products and download permission)

[Darrel O'Pry]

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