Great! I'm glad to see enthusiasm for this project. I believe not only can it be a big plus for Maemo and the N900, but a useful project for open source in general. I'm sure if the framework is robust enough, we can solicit the contributions of academia, or tinkerers world-wide.

Ok, enough of that. Any ideas? This is all new-territory for me, so forgive me if my suggestions sound silly.

Input plugins - For the N900, images can be taken from the camera, but having a generic input plugin makes this useful for other devices, and/or getting images from different sources (fs, internet, etc). Consider that the appropriate input plugin could handle vector imagery as well!

Output plugins - This is pretty straight forward. Having an extensible output system, the output could be xml commands for an autonomous bot. The output should not be limited to a graphic format. Also output to the internet becomes possible.

Temporary filesystem storage - For processing large amounts of data, or storing data for later use. It would be nice if this was an automatic extension of the memory allocation and access system. The benefit of not doing this is swap is a) a much larger scratch pad, b) the potential to optimize reads and writes based upon operations, c) one less thing to think of as the developer (and a pretty big one!).

Node-based architecture - This is a BIG feature, and IMO a must-have. We all know that pipes are useful on the command line. It would be nice to provide an in-code mechanism to easily chain plugins together. PLEASE Check out www.filterforge.com to get a good idea of the possibilities!

Resolution Independence - This seems a bit odd at first, but being able to automatically interpolate lower res images to make them size compatible for comparisons with higher res images would be useful for comparisons.

Language independence - This is a bit of an odd one, but it would be VERY nice to be able to program these plugins in any language. It would be doubly nice to have the library itself easily portable to any number of languages as well. I'm not sure how easy/possible this would be, so feel free to add or strike me down as a raving heretic.

CP (computational photograpy) functions - This is the bread and butter of the application. These CP functions take 0-n resolution independent images, 0-n data inputs, and compute 1-n outputs.

XML rule sheet - This file stores the node structure, which the library can use to load plugins, and determines how to pass information around. This is useful for using the library in a non-interactive, or code-driven way. This would also be necessary for the command-line app.

Plugin controller - It would be nice to be able to break the execution of a plugin after a completed stage, so that the app can prevent runaway situations for complex computations that would take hours on an N900, but would be well suited for a desktop. Perhaps the plugin architecture can allow for this?

Some extra thoughts:

- I think there should be designation for real-time vs slow plugins. Perhaps a different interface for each.
- I think that this should be standards based and avoid re-inventing the wheel where necessary
- I think that it should be an incredibly modular system to allow for disjoined development and easy integration into projects.
- We need a common interface for each category of plugin.

Anybody care to add anything?
Have any ideas for a name?
Any and all input is much appreciated!

}:^)~