ParaQ:Scripting: Difference between revisions
From ParaQ Wiki
Jump to navigationJump to search
(→Design) |
(→Design) |
||
Line 14: | Line 14: | ||
will be followed: | will be followed: | ||
* Clean separation of GUI/engine functionality. All the functionality to be accessed through the scripting | * Clean separation of GUI/engine functionality. All the functionality to be accessed through the scripting interfaceshould be implemented in SM and accesses through the publish SM API by the GUI. | ||
* Stable SM API. Since the scripting interface will depend on the SM interface, SM API should be stable and backwards compatible as much as possible. | |||
* Stable SM API. Since the scripting interface will depend on the SM interface, SM API should be stable and | * Clear and easy-to-use API. The SM API should be clear. Although the SM API is verbose due to it's design, simplifications can be made in the scripting language. | ||
backwards compatible as much as possible. | |||
* Clear and easy-to-use API. The SM API should be clear. Although the SM API is verbose due to it's design, simplifications | |||
can be made in the scripting language. |
Revision as of 08:18, 3 October 2005
Requirements
ParaQ scripting requirements can be found here
Design
ParaQ scripting will be build on top of the server manager (SM) API. Main reasons behind this decision are:
- We need a scripting interface independent of the GUI (accessible through the python client)
- SM is designed to provide such an interface
- SM is already wrapped into Tcl, Python and client/server streams
ParaQ scripts will directly manipulate the SM through it's published API using one or more of the supported scripting languages (Python, Tcl and Java). A python client will be implemented (more on this later). In order to provide a easy-to-use, full featured and backwards compatible scripting language, the following guidelines will be followed:
- Clean separation of GUI/engine functionality. All the functionality to be accessed through the scripting interfaceshould be implemented in SM and accesses through the publish SM API by the GUI.
- Stable SM API. Since the scripting interface will depend on the SM interface, SM API should be stable and backwards compatible as much as possible.
- Clear and easy-to-use API. The SM API should be clear. Although the SM API is verbose due to it's design, simplifications can be made in the scripting language.