See also #7.
If engines are pluggable, then thumbnailer's wsgi application will have to :
read an HTTP request (webobj?)
optionally read some configuration (can be hard-coded by now, then improved in another ticket)
get an "engine" instance, which is at least a callable
use the engine
And engines will have to conform to some API.
Proposal for the core methods:
get_engine_from_request(request). Reads HTTP request, returns a callable.
run_engine(request, document). Calls engine with request and a file object. Returns the result of engine call, which should be a file object.
Proposal for engines:
engines are callable, which take an HTTP request object and a file object as input, and return a file object as output.
Advantage of passing file objects:
the wsgi app receives the request
thumbnailer's core reads configuration, then determine which reader, writer and engine to use
thumbnailer passes the request to the reader, which returns a file object. Default implementation reads an URL passed in the request and returns an Image.
thumbnailer passes the file object to the engine, which returns another file object. It reads options (width and height) in the request.
thumbnailer passes the file object to the writer, which transforms it to an HTTP response. Default implementation returns an image as HTTP response.
With this design:
engines don't have to care about getting the input file.
engines focus on transforming the input file into another file + managing the transformation parameters (width and height)
we can imagine chaining engines (scale + crop + black-and-white), later ;)
we can imagine plugins for writers and readers too (as an example, read from or write to local disk), without breaking compatibility with engines.
See also #7. If engines are pluggable, then thumbnailer's wsgi application will have to :
And engines will have to conform to some API.
Proposal for the core methods:
Proposal for engines:
Advantage of passing file objects:
With this design: