On 16/03/12 09:28, Radek Novacek wrote:
Hello folks,
I've been working on a proof-of-concept of the possibility to automatically
generate agent code (qmf and dbus parts of the agent) from schema.xml. In this
email I'll show you the progress in this feature as well as some changes I
propose to ease creation of new agents.
* Templates in python-cheetah *
Python-cheetah templating system is used for transforming schema.xml to agent
source code and header for the library (explanation will follow). Using this
really simplifies readability of the code. I tried to use XSLT first but the
transformation definition was a mess.
What the Cheetah does?<very simplified explanation> It takes template and
interprets all lines starting with '#' as python code and replace all
variables starting with '$' with their content.
* Generate library headers *
When the QMF/DBus part is autogenerated we need to exactly specify how it will
be glued together with the library. So header file for the library is
generated too and the library implements functions specified there. This way
compiler ensures that all methods are implemented and has expected prototypes.
Since part of the library (headers) are generated from schema, I've decided to
move all the agent-specific libraries from lib/ to agent-specific subdirectory
(like host/). It makes more sense to have the schema.xml and the library code
that implements functions based on the schema in same directory.
* Bonus features *
There is structure called Matahari (not sure if it shouldn't be renamed
somehow) that is passed to all of these methods. It allows some extra
features, like:
- No global variables
One can assign his own structure to private field of Matahari struct
(useful e.g. for sigar instance)
- Error messages
Error messages can be stored in Matahari struct and be passed via
transport method to caller (Qmf and DBus have exceptions for that)
- Asynchronous methods
There is callback method that can be used for async methods. Method in
library just returns MH_RES_ASYNC return code and then call callback item from
Matahari struct when the result is ready
- Easy to add new transport layer
Creation of transformation template is almost the only thing needed to be
done to add a new transport layer and it doesn't require to change agent
libraries.
* Issues *
- callback methods are not type safe (there is cast to generic function
pointer)
- emitting events are not type safe (now it uses variadic arguments)
- setting properties is not implemented - I think we need some standard way
how to set properties since QMF don't support setting the value to properties
directly
- one API incompatibility: QMF product for agents had a different letter-case
(Network vs. service) - needs to have same rules to be autogenerated ->
changed to always uppercase for first letter (same as class name in schema)
I've push the code to my GitHub repo:
https://github.com/rnovacek/matahari/commit/ca169438c51d9efcf9806816f01aa...
Any advice and suggestions are welcomed.
Radek Novacek
Nice patch :)
This seems like it would work well for the case of the core Matahari
agents - one object per agent and based on a purpose-written library. I
don't think this will work for the general case where there are multiple
objects with relations between them, and where the agent is based on an
existing library (libvirt-qmf is an example of an agent with these
properties).
However, there is nothing stopping both types of agents coexisting. The
only downside I can think of is that the core agents would no longer
serve as an example of how to write a third-party agent.
cheers,
Zane.