I like Rafi's idea. As I have advocated before, the most compelling reason to make a C API is the ability to support dynamic languages. Given the popularity of dynamic languages this would be a very important step in taking Qpid to the masses. This approach would allow us to maintain several dynamic language bindings with reasonable effort after the initial investment of getting a well defined compact C library. Projects like Axis2/C has had good sucess using the above approach + swig for their dynamic language support.
I also like the protocol engine to not impose any threading model which then gives the particular language binding the freedom to work with a threading model that best fits it's need. For those familar with Java, an example would be the javax.net.ssl.SSLEngine which provides SSL support and is somewhat conceptually similar to what Rafi is proposing. Regards, Rajith On Fri, Apr 17, 2009 at 9:22 AM, Rafael Schloming <rafa...@redhat.com> wrote: > 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 > > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
