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.
with "standard" APIs hanging off
these where it makes sense to build them.
The standard APIs I think are less confusing as they generally have some
externally defined value or purpose.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
