qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: [c++]: Sketch of a high-level, protocol independent API
Date Fri, 17 Apr 2009 12:35:39 GMT
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-subscribe@qpid.apache.org

View raw message