# Future Plans

A challenging release plan has been developed for Magick++. What actually gets accomplished depends on the level of support from users and developers. Volunteers are needed. In particular, work on the CORBA/COM IDL-base API may proceed in parallel with other development. The following is the tentative development and release plan (step 1.0 is complete).

1.0 API for operating on individual images and STL containers of images

> This version supports all ImageMagick API operations which operate on a single image as well as providing STL container support for operating on multiple images (on any STL compatable container which supports a forward input iterator).

> STL is used as the framework in which to store images. Template functions (e.g. montage) are provided to build the image lists required by ImageMagick and then invoke the list-oriented ImageMagick API. STL is quite powerful yet easy to use. At this stage Magick++ has matched what is currently available/possible using the PerlMagick API due to leveraging the power of STL.

2.0 CORBA and/or COM IDL based client API with server implementation for executing image processing operations on a remote (or local) computer.

> This version provides an IDL-based API. A C++ wrapper API compatable with that developed for release 2.0 is available for use by clients. Client wrappers may also be developed for other languages (e.g. Java). COM and CORBA servers are provided which are implemented in terms of the Magick++ API in order to satisfy client requests (which may run a different operating system than the server).

3.0 Integration of IDL-based API with an existing open source work-queing system in order to load-share image processing tasks and the image frame and file level across a large number of machines.

> This version is the culmination of the effort. By intelligently spreading work over many machines, the performance of ImageMagick is magnified. In order for this to be a success algorithms for efficient transfer of image data must be developed. Algorithms that take into account processor afinity and the CPU vs I/O tradeoff for the task to be performed must be developed. At this point in time, the queuing system to be employed has not been identified.