## Future Plans

At this early stage in development, there is no reason to artificially constrain imagination or ambitions. Therefore, I have laid out a challenging release plan 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 IDL-base API may proceed in parallel with other development. The following is the tentative development and release plan.

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 IDL based client API with server implementation for executing image processing operations on a remote (or local) computer.

> This version provides a standard CORBA 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). A CORBA server is provided which is implemented in terms of the Magick++ API in order to satisfy client requests (which may run a different operating system than the server) . An implementation repository and object activation is used to instantiate the server upon demand to ensure that server machines are not unnecessarily burdended. The CORBA ORB employed is expected to be TAO developed by Doug Schmidt (and friends).

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.