Magick will have the ability to script extra functionality (ie. write custom code without touching
the core Magick code). Magick will then be able to, at various points in Magick's execution make
certain callbacks, which will execute the functions created by the user. When those functions are
finished their processing, they will return control to Magick, and processing will continue. The
scripting language itself will be interfaced with Mantra, and mantra will expose a callback API to
Magick, so that it can invoke the relevant execution.
Many users request features that are either considered by the Development Team to be beyond the
scope of what Magick (the core product) should do (for example, sending emails), or that are
not in line with the direction the Development team wishes to head with Magick. The solution to
this is to create an easy way for users to write the functionality themselves, and get Magick to
hand over to their own code, and take control again once its done.
Another issue we have noticed is sometimes users want things like the default committee which can
run a certain command changed, or the behavior of a certain command to be different, or require
more information, etc. Once again, letting users re-bind commands, and write their own commands
helps with this process, giving Magick much more flexability and appeal to users.
Mantra must be created.
The scripting language we have decided to use is Python.
Python was chosen because it is also natively object oriented, internally multi-threaded, and
fairly easy to embed into a C++ program. It is also becoming more and more popular, meaning
that there is an existing body of people who understand how to use it, and it coming installed
on more and more systems.
The scripting language will first have to be implemented into Mantra first. The interface to
the scripting language should only expose an API consisting of:
Starting and stopping the interpereter.
Loading (or re-loading) a script file.
Unloading a file and its functions (if possible).
Exposing a function (including return codes and parameters), variables, and functions
from the API user to the scripting language for use in scripts.
Exposing an object (and functions, and data items) to the scripting language from the
Checking whether a subroutine exists in the script.
Running a specific subroutine from one of the files that has been loaded with optional
arguments. This should return an integer return value from the subroutine. An exception
should be raised if the function fails to execute for any reason.
Once the scripting language is implemented into Mantra, it should be reasonably easy to implement
the necessary callbacks into Magick. The parameters that should be passed to each callback will
be determined as the callback is implemented, and when this happens, a skeleton callback function
should be implemented in the scripting language.
The current design allows for us to change the scripting language at any time if either another
suitable candidate is found, or if someone wishes to implement the same scripting API for another
language. Therefore, it is possible that Magick may support other scripting languages in the
future, however this is not planned.
If python is not installed on a system, the scripting language will have to be disabled, as we
do not want to distribute python with Magick, and while the user COULD compile python in their
own home directory, its impractical for them to do so.
Magick will be blindly handing off execution control to the python interpereter. There is no
way to account for how long the python interpereter will keep control, or what the script the
user has written (or is using) will do. This could be very dangerous, however the scripting
language will be a 'use at your own risk' deal.
Several sample scripts for EVERY callback that is used by Magick will have to be created.
This includes scripts ranging from simple ones to change the bindings of a commands to be
accessable by a different committee, right up to creating an entirely new service complete
with its own functions and data storage.
Python.
| 
