John,
I agree with every point you make. The FieldTable and Array classes are
pretty horrible to use except for the simple cases and lack consistency
in design. They also expose boost which we are trying to move away
from[1] and tie the encoding details to the data structure[2] and
application visible API. In short, though we will obviously continue to
support it for existing users, I don't think that FieldTable in its
current form is really suitable as part of the exposed API in the long term.
Some time ago the desirability of a higher level API for the c++ client
was discussed and I started some work on that. For the past couple of
months my attention has been diverted by other work but I hope to return
to it now. This API will include a variant type and a corresponding map
of these through which message properties would be accessed. The
intention is also to provide direct support for messages whose content
is an encoded form of a map or list. I still have some details to work
through of course, including how to avoid breaking the existing API
while avoiding expensive conversions.
--Gordon
[1] https://issues.apache.org/jira/browse/QPID-1780
[2] I see we now have two encodings, with qmfEncode/qmfDecode having
been added, but I think the point still holds.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
