On Tue, Feb 13, 2018 at 8:30 AM, Rabih M <rabih.prom...@gmail.com> wrote:
> 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;
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:
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
+1 - we are still in discussion & early prototyping so your input much
> Best regards,
> 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: email@example.com
> > 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