This is the full proprosal from the blueprint for having photo loaders as actions.
1. Reasoning
There are a few reasons to have photo loading moved into actions. The sum of these is flexibility for users and developers.
There is quite a bit of potential for phatch to be extremely useful as is. I have several ideas on how phatch could be extended and integrated into other existing software (e.g. digikam). The first step of this in my mind is to create a more flexible file opening method.
First, allowing for flexible, pluggable (via actions) photo loaders just seems more pythonic.
Second, by allowing for plugable photo loaders a user can choose to point phatch at many photo repositories, not just his local hard drive. Some ideas I've had about this aspect include:
* url loader — a user can point phatch at his webserver photo directory (or that of a friend etc)
* flickr loader — using the flickr api a user can process photos in his stream (which were perhaps put there automatically by his camera). After processing he can put them back in his photostream with a realated save action.
* pipe loader — after some external app spits out an image (say dot) it can be processed further by phatch
Stani: For this we need to implement a cross-platform virtual file system. Maybe we can use itools.vfs (http://www.ikaaro.org/itools/;view#itools.vfs). We should develop our own file object with an open, read and write method.
Third — this allows developers to better create cool uses for phatch. For example, as soon as I saw phatch I decided I would love to modify it to do distributed photo processing. By having a dynamic way of opening files it would be much easier for me to write a phatch-distributor. By doing so I could let the user chose to get files from the local or shared (eg nfs) filesystem, or from the job queue, or from a url and so on, instead of forcing them to do it the way i chose is best.
Stani: This is a good idea, but for that the vfs needs to be implemented first.
2. Suggested plan of attack
A. Create a loader api. I'm not fully sure on this but here is my current thinking (loader is a subclass of action):
* isPhoto(path) — returns boolean. True if the path can be turned into a photo object. otherwise False.
* getPhotos(path, recurse) — returns list of paths (appropriate for this loader) that would return true on a call to isPhoto. This will recurse if recurse is set. It will silently ignore recurse if the loader has no notion of recursion.
* canLoad(path) — return true if i know how to open this path.
* apply(path) — this starts off the processing chain instead of api.get_photo. returns a Photo object form the path
B. Create an AutoLoader action builtin
* getPhotos— goes through all known loaders, and calls loader.canLoad(path), if true, call getPhotos(path)
* default loader (see below)
C. Silently apply load action (using AutoLoader) in check_actions when the first action in an actionlist is not a loader. This allows for easy creation in simple cases, and leaves loader determination to advanced usage.
D. change apply_actions for the current semantics. For the most part this is pretty easy.
E. change the actions directory to have topic based subdirs— e.g. actions/loaders, actions/manipulations, actions/savers. (this also will allow for more development towards advanced actions. I have another blueprint in mind for this but as a teaser: containeractions, that will combine two images in some way and take a container of photos instead of a single photo. this of course has a whole pile of requirements.)
Stani: This would be better designed in a sprint. I would prefer to have first a more low level approach, which could be used outside Phatch as well. Also for external actions, it can be that the image is not loaded into memory (PIL), but resides on the disk so that tools like imagemagick or pngcrush can be called on it. The Photo class has than a descriptor how to it is stored.
3. Cons/drawbacks/snags
There are a couple of issues with this idea. The biggest being loader resolution order. A generic url opener could think that opening a flickr url is good for it, but the more specific flickr loader may be a better choice.
Another drawback is that it makes the action api not as clean. In this scenario some actions would take a Photo, and others would take a path. Im not sure how to resolve this, but there is probably a nice resolution. I also think the benefits of this idea far outweigh this drawback
Stani: I want the api to stay clean and think this is possible implementing a vfs.
4. Erich
This isnt strictly part of the proposal, but I am more than willing to take on the work for this aspect of development. I can be reached at moc.liamg|selcahpos#moc.liamg|selcahpos.
