Refactoring image module: proof of concept

Extracts of devel-list discussion regarding image module refactoring.

[Eric Scouten]

Here's my rather blunt opinion on image.module. It's trying to serve two rather different purposes:

• (1) Serve as a site-wide and/or personal image gallery, providing navigation and categorization of the images.
• (2) Allow users to add individual images to nodes. (Think of them as illustrations for news stories.)

Unfortunately, I think it does neither job well. I think the two purposes should be separated into separate modules.

I have a pressing need for something that does (2) well so I'm working on writing a new module I call attached_image. In my rendition of the module, images are no longer nodes in and of themselves, but rather attachments that live or die with an individual node. Images submitted through this module have no purpose outside of the node to which they are attached.

[Stefan Nategaal]

I'm sure we can use lot's of code, that Marco wrote, but I also think that
we need to split the project again into an;

• - ImageAPI and
• - FileAPI.

the FileAPI can be used to upload/download/manage/delete/administer files,
as where the ImageAPI can provide us with thumbnail generation, image
processing, manipulating images, all using GD1, GD2, ImageMagick or none of
them if they are not allowed at all..

[Moshe Weitzmann]

marco's code fileAPI already includes no image functions. to see the inetraction of how an image based modules uses the API, see fsgallery.module in his sandbox.

to those clamoring for a better image.module, I urge you to contribute *code* in addition to ideas. with the notable exception of bruno, noone has given this module much love since its original birth ... if you think it is a complete mess and want to start clean, you should look at marco's fsgallery.module which already uses the fs API and is far simpler (with fewer features).

[Bruno Rocci]

I agree it is time to refactor image module. Using Marco's fileAPI for the
image file handling, including upload is one interesting possibility, and
probably the best way to go. It will simplify the process but this will be
almost hidden to the end user, which is good actually.

Creating an imageAPI is something I had in mind for a while. But I prefer to
call it transformAPI, because I think making image transformations
more streamlined across the different graphical libraries (ImageMagick,
NetPbm, GD) will bring value. Having image module providing functions to
other modules, dealing with images, to scale, rotate images, to watermark
images, etc would be usefull, I think. But again, from the end user
perspective it won't bring much. It will mainly add flexibility to
administrator.

I see the future of image module as a part of the Drupal core, but in a more
simplified version. Extra features would be part of "companion" modules.
IMHO image module in the core should provide:

• 1. image file handling (including upload) and storage via the file API
• 2. basic image transformations with the most popular image libraries: ImageMagick, NetPbm, GD
  • - scaling, including creation of image "variations" not only thumbnails
  • - rotating (by 90° steps)
  • - text and logo watermarking

This could be extended by external module and supplied as a transform
API.

• 3. filter system to include images in nodes with a choice of sizes
  (thumbnail, small image, original image)
• 4. node based taxonomy support
• 5. support for custom fields (such as photographier name, etc)

The first "companion" module I see is obviously a gallery. We may provide
the same type of gallery as the current one, but the door is open to
implement a gallery in a different way, without impacting the core image
module. If you don't need private image gallery for your users, make you own
simplified image gallery.