On Tue, 2012-06-26 at 16:48 +0100, Gordon Sim wrote:
> On 06/25/2012 06:45 PM, Rob Godfrey wrote:
> > I'm not sure that there is an overall write/wrong API to use... what
> > is important is that we properly define APIs, document them and then
> > support them.
>
> Exactly. So far we have defined and documented the messaging API. We
> need to make sure that we are clear on how any new APIs relate to that
> and what the support is now and will be in the future.
>
> > We should definitely be aiming to avoid creating
> > "competing" APIs within Qpid.
>
> I think some degree of overlap is inevitable; each API presumably
> supports sending and receiving messages.
>
> > So far we have seen low level APIs that
> > are comprehensive, but not necessarily user friendly (e.g. the proton
> > engine API), high level externally defined APIs (such as JMS, WCF),
> > and our own attempt to build user friendly but powerful APIs (the
> > messaging API). On top of proton there's also been some work at
> > producing a simplified API which is at a higher level that all of the
> > APIs above and may not expose the full set of functionality.
> >
> > I think that that gives something like "Simple" < "Comprehensive" <
> > "Low Level" as three levels of APIs
>
> Those distinctions are reasonable hints, but still leave a lot of questions.
>
> What can't I do with the simple APIs? What functionality do the low
> level APIs offer that I can't get from the comprehensive APIs? In what
> way are the comprehensive APIs more 'user friendly'? Will the
> comprehensive API (continue to/eventually) be supported in my language
> of choice? I've just moved to the messaging API, don't #@%!ing tell me
> there's another one?
>
> These are the sorts of questions I think are natural to ask. I just want
> to be sure that _as_a_community_ we are prepared to answer them in some
> way, on the user list as well as any new proton specific list.
>
> While on one level you can point people at the API docs for each and let
> them draw their own conclusions that presents something of a barrier to
> new users.
I think the easiest/most complete way to think about this is as a two
dimensional matrix. On the one hand you have programming model, and on
the other hand you have protocol exposure/control.
Protocol Control
P
r Limited | Full
o +-----------+-----------+
g Blocking | | |
------+-----------+-----------+
M Non Blocking | | |
o +-----------+-----------+
d
e
l
In the lower right quadrant you have the engine API which is designed to
give you full control over every important aspect of the protocol and
does not limit your programming model at all. In the upper left quadrant
you have the messenger API which provides a significantly simplified
interface (i.e. the API version of drain and spout), but doesn't give
you direct control over how the protocol is used, and assumes a blocking
programming model. In the upper right quadrant you have the messaging
API which gives you direct control over link/session/connection
creation, and assumes a blocking programming model. Right now we have
nothing in the lower left hand corner, but you can imagine an extended
messenger API that would fit into that area.
--Rafael
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
