So there is quite a bit of duplicated code and convoluted interfaces for manipulating files. especially images...
imagecache, image, watermark, imageexact, etc, etc are all relatively simple 'filters' or 'processors' for files. I've got different versions of imagecache with various gd filters, image2ascii conversion, mosaic affects, etc floating around, along with some tools for processing quicktime files and front-ends for ffmpeg I'd like to make available to the community, but coding a module for each one would be a real pain, and would make for a rather module heavy drupal...
imagecache is really a proof of concept work for generating images on the fly, but I had to throw the 'preset' and 'action' management interface into it so it could do its good work. I think there is a strong need to sort this kind of processing into its own little library. Actions.module or filter.module would be a good model for a UI I think.
Basically we need to be able to group processors into macros or chains that can be named and developed by users. Then the modules that need access to file processing features will have a consistent way to query which processors are available for a given file, and run them.
See attached sample processor plug-in... I'd like feedback on the plug-in format.
| Attachment | Size |
|---|---|
| crop.processor.txt | 1.97 KB |
Comments
use fapi callback model
adrianR gave a fapi 3.0 talk in brussels which started to look a lot like macros and such. the idea is that the plugins register themselves using something like submit handlers. but his handlers were a bit different. you really have to hash it out with him, cuz it was over my head in places.
Filters
By speaking of filters, I don't know if this might be interesting for you - Inline module will/needs to be extended to a plugin system (see issue Inline API) in the near future.
Daniel F. Kudwien
unleashed mind
Daniel F. Kudwien
netzstrategen