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. If you must go straight for an object model,
then do
please evolve the swig specifications at the same time.
I suspect that what you are interested in is what I would choose to use
to implement
such an API internally. Which means that essentially I *do not care*
what it looks like,
and think it needs no API stability at all.
It may be appropriate to bless it for direct use at some future time,
but hopefully that
would be when no-one can be bothered to refactor it any more because its
good
enough. I'd hate to try to go from 0 to a working 'good' object API in
one step.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
