On 07/15/2011 11:39 AM, Zane Bitter wrote:
Since libvirt-qpid (or, rather, libvirt-qmf) seems to be the first
matahari agent to be created outside of the matahari package, I have
collected a few observations gathered from writing it. One big caveat
here is that this applies only to the QMF side of things; I have spent
no time with DBus to date.
1) Missing headers
I've already added a patch to export mainloop.h. I think we also need to
export logging.h. Also note that these headers currently don't have the
mh_ prefix. Maybe that's not really required because they are in the
matahari/ directory already, but it's not consistent.
(Incidentally, this change needs to be in Fedora before we can add the
libvirt-qmf package since the latter won't build without it.)
Let's get this fixed then, ideally before the F16 feature freeze date of
Jul 26
2) Oddly-named libraries
On the subject of prefixes, the prefix used for the matahari libraries,
namely "m", is... not the *most* effective thing for avoiding name
collisions that I could think of, nor the easiest thing to search for.
Suggestions? If we're going to change things, _now_ would be the time
to do it before we get into Fedora and need to keep a stable ABI forevermore
3) No stable ABI
In the past matahari has had to be regularly rebuilt due to the lack of
a stable ABI in qpid-cpp. This has now been fixed in the QMFv2 API, but
the lack of the same sort of provisions in matahari means that we will
potentially be creating the same sorts of issues for downstream projects.
My thought is that once we get through this F16 inclusion hurdle, we
need to maintain stable ABI/API going forward. That means we can add
new functions, properties, agents, etc, but we can never remove or
change the semantics of existing functions.
This should just be something we enforce during patch reviews, and we
should state which release of Matahari will be considered ABI/API stable
going forward.
4) Simplistic object model
All of the internal agents publish only a single object. It's even
hard-wired into the MatahariAgent class even though it is not required
there (I have a patch to change this). Y'all will have noticed that I
had to write a bunch of helper classes to simplify handling of the
multiple objects that libvirt-qmf manages. Even now, it's still doing a
horrible linear lookup to do method dispatch. I'd like to replace this
with something (in matahari) that registers the objects and does method
dispatch from a hash table. (Oddly, QMFv1 provided helpers for method
dispatch, but QMFv2 does not seem to... if anybody has better
information I would be interested to hear it.)
I'm not opposed to this, but we'll see what others think
5) Limited support for error handling
Returning an error from a function in such a way as to return anything
other than a generic error code and a string is surprisingly complicated
in QMFv2 (again, if anybody knows any easier way I'd like to hear it).
There is an MH_NOT_IMPLEMENTED string defined, but that is the only one.
And using it still results in the error code STATUS_EXCEPTION, even
though there is an error code in QMF(v1) for STATUS_NOT_IMPLEMENTED.
This seems like an area where matahari could add value.
cc'ing Ted/Chuck to see if they can help with the two QMF specific
questions above.
Since widespread adoption of matahari depends in large part on other
folks wanting to write matahari agents to expose their APIs, I think it
would be valuable to address some of these areas to make it easier for
them to do so. Preferably before any other agents get out in the wild,
so that we are not shifting the goalposts for other projects. Comments?
Agree 100%. Let's resolve some of the questions above and try to get
this stuff better for Jul 26th
Thanks for providing your thoughts as you went through the libvirt-qpid
conversion process :)
Perry