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.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
