On Tue, Feb 13, 2018 at 8:30 AM, Rabih M <rabih.prom...@gmail.com> wrote:
> Hello, > > As Olivier said at Murex we wrote a small C++ client with an imperative API > that wraps proton. At that time we did not know that the community had > plans to develop one. > > The API we wrote was inspired from JMS (connection, session, messaging > producer, messaging consumer...). So the whole thing is similar to Qpid-Jms > wrapping Proton-J. > > What design are you thinking about? > > We are thinking along similar lines, see also the old qpid::messaging API which is quite JMS like. The main weakness of those APIs is the difficulty of handling asynchronous events and flow control, and an inability to write server-like applications. The goal is to come up with something that can be used like JMS or qpid::messaging for simple cases, but also allows a more asynchronous style of programming - without inversion of control. The thinking so far is to use queues and futures (or similar features depending on language) to handle async events so that you can write multi-threaded clients/servers or single-threaded apps that fire off a bunch of work in parallel, then react as things complete (rather than a synchronous send/wait; send/wait; send/wait pattern.) We have one imperative API so far in Go, with a good example of how the imperative style reduces coding for a simple broker example: https://github.com/apache/qpid-proton/tree/master/examples/go#a-tale-of-two-brokers In Go we use the native channel mechanism, which combines the features of futures and queues. In C++ we might be able to use std::future, but it is likely that we will need to add some queue-like primitive of our own. The big difference between Go coroutines and posix-like threads is scheduling efficiency. In Go it is reasonable to make every concurrent task into its own goroutine. In C/C++ it is not efficient to create a thread for every activity in a server that handles 1000s of concurrent connections - hence the event-driven model to multiplex onto a small thread pool. However for small-scale servers or clients that just want to create a handful of threads (e.g. to talk to a handful of back-end services) it *is* efficient to use a thread-per-activity - that's where a concurrent-friendly imperative API comes in. Also many languages (including C++) are moving towards some form of coroutine support so eventually the concurrent+imperative model will be efficient even for large scale servers. We would like to unify our effort with the community to have a working > C++ imperative > client. > +1 - we are still in discussion & early prototyping so your input much appreciated. > Best regards, > Rabih > > On Tue, Feb 6, 2018 at 5:54 PM, VERMEULEN Olivier < > olivier.vermeu...@murex.com> wrote: > > > Hello Justin. > > > > Good to hear. > > Maybe we could also send you what we did on our side. > > It's still pretty basic but it can be a starting point. > > > > Olivier > > > > -----Original Message----- > > From: Justin Ross [mailto:justin.r...@gmail.com] > > Sent: jeudi 1 février 2018 14:37 > > To: users@qpid.apache.org > > Subject: Re: C++ imperative client API > > > > Hi, Olivier. It's still in prototype and research mode. We don't have > > anything like a design proposal yet. I hope we'll have more time to work > > on it soon. > > > > When we have some concrete design points and sample code for evaluation, > > we'll share it here so we can have an open design discussion. > > > > On Tue, Jan 30, 2018 at 12:29 AM, VERMEULEN Olivier < > > olivier.vermeu...@murex.com> wrote: > > > > > Hello, > > > > > > We already discussed with some of you our need @Murex for a C++ > > > imperative client API. > > > I remember Justin saying that you were making progress on this subject > > > but I can't seem to find any information about it. > > > Could you give us a quick status on this? Note that we would also be > > > interested in contributing to the development of this new client. > > > > > > Thanks, > > > Olivier > > > ******************************* > > > > > > This e-mail contains information for the intended recipient only. It > > > may contain proprietary material or confidential information. If you > > > are not the intended recipient you are not authorised to distribute, > > > copy or use this e-mail or any attachment to it. Murex cannot > > > guarantee that it is virus free and accepts no responsibility for any > > > loss or damage arising from its use. If you have received this e-mail > > > in error please notify immediately the sender and delete the original > > > email received, any attachments and all copies from your system. > > > > > ******************************* > > > > This e-mail contains information for the intended recipient only. It may > > contain proprietary material or confidential information. If you are not > > the intended recipient you are not authorised to distribute, copy or use > > this e-mail or any attachment to it. Murex cannot guarantee that it is > > virus free and accepts no responsibility for any loss or damage arising > > from its use. If you have received this e-mail in error please notify > > immediately the sender and delete the original email received, any > > attachments and all copies from your system. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > > For additional commands, e-mail: users-h...@qpid.apache.org > > > > >
