Now that the Serial I/O support, for Posix anyway, has been completed, I wish to add Bayonne's scripting engine to Common C++ next. The Bayonne script engine is destined not only for the Bayonne ACS telephony server, but for serial based telephony switch integration servers. Perhaps there are other projects that can use it as well.
For those not already familiar with Bayonne or ACS scripting architecture, the script engine essentially operates as a class extensible engine whereby compiled script commands are directly mapped to member functions. The core engine then step executes a selected member function with the script paramaters and branches based either to the next script step, to a named branch point, or based on a signaled event. Each execution of the engine represents one "step" through the engine, and there is no hidden recursion or expression parsing. This is done entirely to assure very short execution times within the engine for each descreat step and differs from the design goal and execution model of other less determenistic embedded scripting systems such as tcl.
The Common C++ script engine is essentially meant as a generic and easily extensible replacement for the core engine found today in ACS. The syntax and method of operation will be roughly similar, though Common C++ will only itself contain a core subset of the scripting language; applications will derive specific dialects with application specific features. Other key ACS concepts, such as persistant core images until all active sessions complete will be kept to assure realtime performance when rebuilding/loading scripts in a running application.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Forgive my ignorance, but I have just started to read the docs. Could you clarify "each execution of the engine". It seems to imply a process or thread instantiation, but that doesn't make sense to me. A generic script engine library seems nice, though. I remember trying to parse other peoples C callbacks to work with script libraries. I guess that in this case, you are adding a new class for each script command? Also, what did you use to generate the html class docs, maybe I can help update it while I study CommonC++. -Rich
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In ACS and the Bayonne script engine in particular, you derive a single new class for the entire application specific dialect rather than create a new class for each individual script command, and your new commands are implimented as new member functions in your derived class. In ACS, these new members had to appear as virtuals in the base class, and hence the base class had to be aware of the entire language even if it didn't include implimentation for more than a subset. In the Bayonne engine, new script commands do not have to appear in the library base class as member functions at all!
The docs are generated out of a known "good" version of kdoc, such as the one that comes with Mandrake 7.0.
When speaking of "step" execution, this is precisely to perform execution steps in response to/via a callback thread; a given thread may service steps in many indipendently executing instances. This is another area where ACS and the new Bayonne engine differ from most of the conventional embedded script languages, and particularly from the tcl execution model.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now that the Serial I/O support, for Posix anyway, has been completed, I wish to add Bayonne's scripting engine to Common C++ next. The Bayonne script engine is destined not only for the Bayonne ACS telephony server, but for serial based telephony switch integration servers. Perhaps there are other projects that can use it as well.
For those not already familiar with Bayonne or ACS scripting architecture, the script engine essentially operates as a class extensible engine whereby compiled script commands are directly mapped to member functions. The core engine then step executes a selected member function with the script paramaters and branches based either to the next script step, to a named branch point, or based on a signaled event. Each execution of the engine represents one "step" through the engine, and there is no hidden recursion or expression parsing. This is done entirely to assure very short execution times within the engine for each descreat step and differs from the design goal and execution model of other less determenistic embedded scripting systems such as tcl.
The Common C++ script engine is essentially meant as a generic and easily extensible replacement for the core engine found today in ACS. The syntax and method of operation will be roughly similar, though Common C++ will only itself contain a core subset of the scripting language; applications will derive specific dialects with application specific features. Other key ACS concepts, such as persistant core images until all active sessions complete will be kept to assure realtime performance when rebuilding/loading scripts in a running application.
Forgive my ignorance, but I have just started to read the docs. Could you clarify "each execution of the engine". It seems to imply a process or thread instantiation, but that doesn't make sense to me. A generic script engine library seems nice, though. I remember trying to parse other peoples C callbacks to work with script libraries. I guess that in this case, you are adding a new class for each script command? Also, what did you use to generate the html class docs, maybe I can help update it while I study CommonC++. -Rich
In ACS and the Bayonne script engine in particular, you derive a single new class for the entire application specific dialect rather than create a new class for each individual script command, and your new commands are implimented as new member functions in your derived class. In ACS, these new members had to appear as virtuals in the base class, and hence the base class had to be aware of the entire language even if it didn't include implimentation for more than a subset. In the Bayonne engine, new script commands do not have to appear in the library base class as member functions at all!
The docs are generated out of a known "good" version of kdoc, such as the one that comes with Mandrake 7.0.
When speaking of "step" execution, this is precisely to perform execution steps in response to/via a callback thread; a given thread may service steps in many indipendently executing instances. This is another area where ACS and the new Bayonne engine differ from most of the conventional embedded script languages, and particularly from the tcl execution model.