I have started work on a C++ binding to the Proton reactor event based model with an eye to providing an API very similar to the python client.
I have put together a skimpy skeleton of an implementation with enough corners cut to get a simple HelloWorld example to run, mostly to get myself acquainted with most of the moving parts. This can be seen at https://github.com/apache/qpid-proton/pull/18 I plan to get some JIRAs going on the topic and do my initial work in some branch on my github account. I welcome comments from anyone with ideas on the shape this should take and welcome any assistance anyone might wish to provide in it's implementation. The broad goals are: to make it easy to write simple programs natural to build out more complicated ones very similar API to the Python client lean and performant The choice of C++11 language features to include or leave out is still a question mark in my mind. I am currently trying to hedge my bets on this by introducing such features conservatively (and with plenty of notice). The downside is that C++11 language features are not available in older development systems, i.e. Visual Studio 2008 and gcc for RHEL 5. On the other hand, a non-trivial subset is available in VS2010 and most newer compilers, and this is after all a new C++ API on an "Advanced" message queuing protocol. Another big question in my mind is the desired level of multi threading support. Some event driven systems view threading as the devil's trickery and eschew thread safety guarantees and multi threading support entirely. Perhaps thread safety without multi threading support could be a valuable feature of the API, allowing the programmer to ignore the issue (at the expense of some locking overhead). Dispatch currently manages some significant multithreading use of Proton, but it does not use the reactor. Similar grained multi threading in the proposed C++ client looks quite possible with minimal locking overhead (you can set a pn_collector_t per connection and pn_event_t pools are already managed per collector... nice). Perhaps there are other thorny issues I haven't noticed plus there are remaining known outages in the pn_io_t interface that need fixing. If the API is implemented similar to previous qpid C++ client work, using Handles and PIMPL, presumably the implementation of multithreading could be deferred without affecting the API (unless the lack of Boost derails things somehow). Cliff
