On Tue, 14 Jan 2020 at 11:01, Oleksandr Rudyy <oru...@gmail.com> 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 transactions yet. I suppose
> it is still work in progress and transaction support will be added later.
> Do you plan to add transaction support?

Definitely something I'd like to consider how it will be added, but in
some cases doing so might be low priority based on existing cases; e.g
some of the existing client APIs/bindings already either only barely
support transactions or dont support them at all.

> * the suggested API defines a message class which can be instantiated by
> calling constructor and passing a body. I assume that passing
> List/Map/Dictionary/bytes would result in creation of corresponding body
> section suitable for the type. I assume  custom message body types will not
> be supported by the API. Otherwise, some body decoder/encoder would need to
> be provided via API.

Yes, in many cases I'd expect amqp-value to be used, perhaps a data
section in some.

For more complicated cases, perhaps a specific message type or
additional controls to facilitate more advanced usages could be added
(e.g, one case to consider might be streaming payload data).

> * the message settling is  delegated to Tracker class in case of sender and
> Delivery class in case of receiver. I suppose it is done to encapsulate
> delivery state, tag and id. Why settling functionality cannot be
> implemented on a message class? That might make API simpler and eliminate
> the need for Tracker and Delivery classes...

There are a few nice things from that, e.g the tracker and delivery
could be lighter weight, allowing not having to retain the entire
messages longer than desired when processing, or alternatively allow
reusing the objects e.g you could send one message multiple times and
have distinct trackers, it could enable different message types etc.

> * Would it be possible to specify the message settling modes (for sender
> and receiver) via suggested API?

Yes, there are options that can be passed when creating
senders/receivers/etc to control various behaviours etc such as that.

> * What about receiver credit management? How session and receiver credits
> can be specified by the end user?

I believe the idea is to default to a credit window, (configurable per
options as above) as most of the existing APIs do, but provide means
for manual credit control if its wanted.

The latter looks to still need added in the API doc (well, it does
currently refer to
http://www.ssorj.net/pumpjack/core/receiver/index.html#add-credit from
the window option, but thats really representing existing engine stuff
and so is slightly different if very similar).

> Kind Regards,
> Alex
> On Mon, 13 Jan 2020 at 12:40, Justin Ross <justin.r...@gmail.com> 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
> > 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 - they're important - but for some use cases, the
> > absence of a high-level command-oriented API for AMQP messaging is a source
> > of inconvenience.
> >
> > This inconvenience comes in two forms.  First, JMS is helpfully imperative
> > (in part - it contains multitudes), but it doesn't expose some of the
> > things you can do with AMQP.  And it can't reasonably expose those things,
> > because that would break the contract of the JMS API.  Second, the Proton
> > APIs, since they are reactive, make it harder to handle cases where you
> > need to sequence the processing of events.
> >
> > The imperative client API we are talking about here uses modern language
> > support for futures or coroutines.  Most of the API's operation is
> > asynchronous, but you can easily introduce blocking where you need to.
> >
> > It's a client API only.  We think a comparably high-level server API would
> > be its own dedicated thing, functioning more like Python Flask or JAX-RS.
> > In any case, the Proton reactive API is already a good fit for writing
> > servers.
> >
> > We have the outline of the API and some proof-of-concept implementations,
> > but much remains to be done.  We anticipate that this work will ultimately
> > become a sub-module of Proton, such as proton/client.
> >
> > The API spec:
> > http://www.ssorj.net/pumpjack/client/index.html
> >
> > I've worked on the Python prototypes, so I'll share them here.  I did these
> > some time ago, so they need updating for the latest API spec changes, but
> > they serve to show how the API can use futures or coroutines.  (For Python,
> > coroutines are the preferred approach.)
> >
> > Python prototype (future-based):
> > https://github.com/ssorj/gambit/blob/futures/python/demo.py
> > https://github.com/ssorj/gambit/blob/futures/python/gambit.py
> >
> > Python prototype (coroutine-based):
> > https://github.com/ssorj/gambit/blob/asyncio2/python/demo.py
> > https://github.com/ssorj/gambit/blob/asyncio2/python/gambit.py
> >
> > Some of the other folks who have done exploratory work will follow up on
> > this thread to show what they've done.
> >
> > Some caveats: this is in early stages, and the API will change as we
> > discuss it more.  There are also big outstanding pieces to look at, such as
> > reconnect and failover, to name just one.
> >
> > Thanks for your time, and please let us know what you think.
> >

To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Reply via email to