qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <rafa...@redhat.com>
Subject Re: [c++]: Sketch of a high-level, protocol independent API
Date Fri, 17 Apr 2009 13:22:59 GMT
Alan Conway wrote:
> 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.

My reason for being interested in a C API is for something to be 
embeddable from python/ruby/php/perl/etc, as well as something that is 
suitable for embedding inside both a client and a broker, and I'm not 
convinced the above approach is enough to result in something that is 
useful for that sort of thing.

For embeddability what we need is a strong separation between the active 
and passive portions of the code, i.e. the client needs to be structured 
as a passive "protocol engine" and an active "driver". The protocol 
engine gets fed bytes/frames/etc on its input and produces high level 
events on its output, and the driver is responsible for feeding the 
protocol engine bytes and processing any high level events that result.

This split captures all the complex protocol logic into a single 
embeddable piece, but doesn't force a threading and/or (b)locking model 
onto the embedding application, e.g. I can embed the protocol engine 
easily inside a broker and client and use a nonblocking driver in the 
former case and a blocking driver in the latter case.

This also has the benefit of avoiding callbacks across bindings since 
the protocol engine will only ever produce events when it is fed data, 
so the driver can easily check for and dispatch events without relying 
on callbacks. This is a fairly critical feature for embeddability, it 
means we can do things like trivially use swig to expose the protocol 
engine in just about any language, and then integrate with the native 
threading constructs available in that language, e.g. I can use realtime 
threads in RT Java if I want to.


Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message