Wikimedia Bugzilla is closed!

We've kicked this idea around for some time but haven't yet implemented it.
It would be great to have a nice little daemon for doing image resizes safely:

* No more ImageMagick shell-character-exploit or buffer-overflow scares
* Reduce and unify library and subprogram dependencies for application servers
(vs varying versions of ImageMagick, librsvg, libart/cairo, freetype, etc)
* Integrate a nice SVG renderer like Batik
* Potential to isolate CPU and memory usage by running on separate boxes

Requirements:
* downscale PNG -> PNG
* downscale JPEG -> JPEG
* downscale GIF -> GIF
* rasterize SVG -> PNG
* The SVG renderer must be used in a restricted mode: a SVG must not be able to
include resources loadeded from disk or the network, as this could be a security
vulnerability.
* Any alpha-transparent PNGs must set the background color chunk to white
to avoid weird unexpected colors in old versions of IE.
* Application servers should be able to communicate with the daemon by a
standard, easy to integrate protocol such as HTTP. A simple REST interface
is preferred over XML-RPC or SOAP.
* If in Java, should be possible to compile with Eclipse compiler and run
with GNU Classpath and an open-source VM, even if we use another VM in
production for performance preferences.

I'd like to see also:
* Better control over output format (grayscale staying grayscale, avoiding
wasted bandwidth etc)
* If possible, 'safe' memory usage for resizes of large PNGs as well as JPEGs.
Loading a 10kx10k pixel bitmap into memory to make a 100x100 thumbnail doesn't always end well.
* Other file formats welcome.

There are two main possibilities for data transfer:
* POST an upload of the source file, and receive the data back. MediaWiki
will deal with reading the file from disk and saving the thumbnail back.
* Send and receive pathnames (or partial pathnames). Daemon will handle
disk access, and simply return a file references.

The path references are likely more efficient, but may require sanitizing
for safety.