Gordon Sim wrote:
James Mansion wrote:
Gordon Sim wrote:
James Mansion wrote:
My question is: why do you feel the need to create something
materially different, and why in particular does
a messaging API need to be much more complex for normal use?
Could you elaborate a little on what aspect(s) you feel is/are much
more complex?
Well, I'd look to replace class instances with handles and collaps as
many fancy option
setting/getting functions to a simple interface that uses string
property names and put/get.
And I'd expose a C API as much as possible with limited use of
callbacks and buffer
assignments in the user code rather than having to ask the API to
delete buffers (or,
worse, assume that the user code and API are sharing a heap manager).
I would also look to have the API buffer received messages and use the
simplest
notification mechanism available. So I'd suggest not starting with
any fancy class
structure at all, but first ask how you will integrate into
applications' event loops.
This is something that the MQ API is poor at from memory.
Its not necessary for fancy stuff that configures special options to
be fast, and having a
very stable binary API is handy. Also having an API that can be
trivially wrapped
with Python CTypes or P/Invoke is handy - not least its also easy to
wrap with
other tools such as swig.
Ok, so simple for you is avoiding fancy things, not just the ease of
writing programs to the API? Thats certainly a fair point and I think a
c API would be a great addition to the project. I'm still keen on a c++
API myself; it could at some point in the future be implemented on top
of such a c API.
Given the current state of affairs I'd say the following is the most likely path
to a C API:
1. Clean up, simplify and remove protocol-specifics from the C++ API. Use
handles to hide impls (in particular PIMPL the Message class) use a single
callback interface (MessageListener)
2. Implement a C API over this C++ API for scripting languages, C projects etc.
3. (maybe) bless the C API and move it inwards to the heart of the client lib,
move more of the client lib to C. Not clear (to me) if this is going to be
desirable but once we have a C API it becomes easier to weigh the pros & cons.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
