So there would finally be an asynchronous API, which would use async/await
(Python 3.5+?) ?
Ivan
On Mon, Jan 13, 2020 at 2:40 PM Justin Ross wrote:
> Hi, everyone. For a while now, some members of the Qpid community have
> been working on a new style of messaging API. It now has a reasonable
On Tue, 28 Jan 2020 at 22:35, Alan Conway wrote:
> On Mon, Jan 27, 2020 at 7:44 AM Justin Ross wrote:
>
> > I like to think of the message as a pure value object. As a result, it
> can
> > have whatever lifecycle the API user chooses. For me, that's a reason to
> > isolate it from the
On Mon, Jan 27, 2020 at 7:44 AM Justin Ross wrote:
> I like to think of the message as a pure value object. As a result, it can
> have whatever lifecycle the API user chooses. For me, that's a reason to
> isolate it from the delivery and tracker, because they do have more tightly
> defined
Hello,
I will share our "work in progress" for the C++ implementation even if it
is not ready yet: https://github.com/rabih-mourad/qpid-imperative-proton
There is plenty of refactoring to do and API alignment to make...
Best regards,
Rabih
On Mon, Jan 27, 2020 at 4:35 PM Rabih M wrote:
>
Hello,
We (Murex) are very excited about this new imperative API project.
We are using proton C++ on the client side for some years now and we
experienced the difficulties this model has, as Justin described in his
first mail.
On our side, we began implementing the new API in the C++ language and
I like to think of the message as a pure value object. As a result, it can
have whatever lifecycle the API user chooses. For me, that's a reason to
isolate it from the delivery and tracker, because they do have more tightly
defined lifecycles.
If there was a substantial win in convenience, I
On Wed, 22 Jan 2020 at 09:39, Rob Godfrey wrote:
>
> On Tue, 21 Jan 2020 at 18:31, Robbie Gemmell
> wrote:
>
> > On Tue, 21 Jan 2020 at 17:06, Rob Godfrey wrote:
> > >
> > > On Tue, 21 Jan 2020 at 16:38, Robbie Gemmell
> > > wrote:
> > >
> > > > On Tue, 21 Jan 2020 at 14:28, Rob Godfrey
> >
On Tue, 21 Jan 2020 at 18:31, Robbie Gemmell
wrote:
> On Tue, 21 Jan 2020 at 17:06, Rob Godfrey wrote:
> >
> > On Tue, 21 Jan 2020 at 16:38, Robbie Gemmell
> > wrote:
> >
> > > On Tue, 21 Jan 2020 at 14:28, Rob Godfrey
> wrote:
> > > >
> > > > On Tue, 21 Jan 2020 at 14:24, Robbie Gemmell <
>
On Tue, 21 Jan 2020 at 17:06, Rob Godfrey wrote:
>
> On Tue, 21 Jan 2020 at 16:38, Robbie Gemmell
> wrote:
>
> > On Tue, 21 Jan 2020 at 14:28, Rob Godfrey wrote:
> > >
> > > On Tue, 21 Jan 2020 at 14:24, Robbie Gemmell
> > > wrote:
> > >
> > > > On Tue, 21 Jan 2020 at 11:21, Rob Godfrey
> >
On Tue, 21 Jan 2020 at 16:38, Robbie Gemmell
wrote:
> On Tue, 21 Jan 2020 at 14:28, Rob Godfrey wrote:
> >
> > On Tue, 21 Jan 2020 at 14:24, Robbie Gemmell
> > wrote:
> >
> > > On Tue, 21 Jan 2020 at 11:21, Rob Godfrey
> wrote:
> > > >
>
>
[... snip ...]
> > >
> > > > 6. receiver-options -
On Tue, 21 Jan 2020 at 14:28, Rob Godfrey wrote:
>
> On Tue, 21 Jan 2020 at 14:24, Robbie Gemmell
> wrote:
>
> > On Tue, 21 Jan 2020 at 11:21, Rob Godfrey wrote:
> > >
> > > So... a few initial thoughts / queries from a brief look through. I'll
> > try
> > > to do a more detailed review later
On Tue, 21 Jan 2020 at 14:24, Robbie Gemmell
wrote:
> On Tue, 21 Jan 2020 at 11:21, Rob Godfrey wrote:
> >
> > So... a few initial thoughts / queries from a brief look through. I'll
> try
> > to do a more detailed review later
> >
> > 1. I don't see any mechanism for connection retry /
On Tue, 21 Jan 2020 at 11:21, Rob Godfrey wrote:
>
> So... a few initial thoughts / queries from a brief look through. I'll try
> to do a more detailed review later
>
> 1. I don't see any mechanism for connection retry / alternate hosts in the
> connect operation / connection-options parameter ;
So... a few initial thoughts / queries from a brief look through. I'll try
to do a more detailed review later
1. I don't see any mechanism for connection retry / alternate hosts in the
connect operation / connection-options parameter ; further I presume there
is no mechanism for attempted
As a follow on to the prototyping work Justin has done for python I wanted
to also point to the work Robbie and myself have been doing around an
imperative API based Java client. This client follows the basic API
guidelines for a futures based client as outlined in the API specification :
On Tue, 14 Jan 2020 at 11:01, Oleksandr Rudyy wrote:
>
> Hi Justin,
>
> Thanks for sharing the results of you work on a new API.
>
> I briefly looked through the suggested design and POC and the following
> questions sprang into my mind:
>
> * the suggest API does not have any notion of
Hi Justin,
Thanks for sharing the results of you work on a new API.
I briefly looked through the suggested design and POC and the following
questions sprang into my mind:
* the suggest API does not have any notion of transactions yet. I suppose
it is still work in progress and transaction
Hi, everyone. For a while now, some members of the Qpid community have
been working on a new style of messaging API. It now has a reasonable
shape, and we want to share it and get your feedback.
We currently offer either JMS or Proton's reactive API. These certainly
aren't going anywhere -
Hi, everyone. For a while now, some members of the Qpid community have
been working on a new style of messaging API. It now has a reasonable
shape, and we want to share it and get your feedback.
We currently offer either JMS or Proton's reactive API. These certainly
aren't going anywhere -
19 matches
Mail list logo
