Mantra

Summary

Mantra will be a library that contains all of the code that is not specific to Magick. It is likely that other products may eventually use Magick, as the technology that will be contained within is very advanced, and rarely available in a decent package. However, it will primarily be designed to perform all the functions that Magick needs.

Justification

1. Magick is too dependant on certain technologies (eg. ACE), in that it would be very difficult to change to a different set of technologies if the need arose. Add to this, that as new features arise (eg. the scripting language), if we dont have something like Mantra in place, the Magick code will become more and more difficult to maintain.

2. In the future, we plan on adding things like a data storage abstraction layer, so that users may choose how their Magick data is stored. To do this, we need a common interface that Magick can use, without caring how the data is stored or retrieved. This requires an API, and thus, Mantra.

3. Others in the development community have expressed great interest in the technologies that form the basis of Magick. For example, the tracing technology. These technologies are very Magick specific right now, and also are licensed under the same license as Magick, making it difficult for others to use. By creating Mantra, we will remove the specific nature of them (to Magick), and be able to re-license just these technologies, so that others might use them.

Pre-Requisites

Which technolgoies in Magick to be moved to Mantra must be determined.

Implementation

Mantra will be implemented in stages.

1. We must assemble all the code that we are pulling out of Magick into its own directory. We must also pull the necessary includes from the Magick pch.h.

2. We must create Mantra functions that duplicate all the ACE functions that are currently in use by Magick. This means making our own classes, etc. that mirror at least as much of the API of ACE as we are using. Initially, these classes will just be inherited from the ACE ones.

3. We must convert all the classes we inherited from ACE into an ACE interaction layer, which will conform to as set of 'External Intergration Layer' standards. By conforming to these standards, we will have a list of functions which we will HAVE to implement to be able to replace ACE, if we desire to.

4. We must create a new cohesive API that we will expose to anyone using Mantra. This API should interact with one of the External Intergration Layers, but should not expose it directly.

Mantra must handle all system-specific operations Magick does, including threading, locking, signal handling, etc. Mantra should also handle anything currently being handled by ACE, including things like events, timers, etc. Finally, Mantra will also take over many functions implemented in Magick itself, such as tracing, the tokenized locking system, etc.

This spec should be updated with more speicific information as deeper analysis is done.

Potential Problems

Certain technologies will have to be replaced, this could alter the way Magick works.

Test Plan

Full regression test, Magick should work exactly as it did before, just linked to Mantra.

Glossary

ACE: The Adaptive Communications Environment.