ParaQ:Scripting: Difference between revisions
From ParaQ Wiki
Jump to navigationJump to search
(→Design) |
(→Design) |
||
Line 9: | Line 9: | ||
* SM is already wrapped into Tcl, Python and client/server streams | * SM is already wrapped into Tcl, Python and client/server streams | ||
ParaQ scripts will directly manipulate the SM through it's published API. | 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 interface | |||
should 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. |
Revision as of 08:17, 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 interface
should 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.