John O'Hara wrote:
Now we just need to decide the shape of that lower level API. There
is a lot of talk in the AMQP camp about doing a standard shape API.
We already have some candidates in the wild from iMatix, Apache, and
Rabbit, and there have been side discussions about having a beauty
contest or doing pick'n'mix.
The API needs to look good and feel right. I get terrified when I
think of the last thing that tried to standardise an API shape across
languages -- DOM. I'm sure we can have something nicer looking than
that ;-)
Comments?
I think there are two issues here:
(1) standardising an API for a particular language to allow applications
written to that API to easily move from one client implementation to
another, and
(2) aiming for 'consistency' across APIs in different languages
The first only makes sense in connection with other implementors, and is
in my view premature.
The second is something we can do within the qpid project. As has been
mentioned before, a degree of consistency would come automatically from
a direct translation of the AMQP 'methods' into native methods in each
language (differences will emerge even at that point based on support
for optional arguments and default values). The message abstractions are
an other area to consider as well as the handling of incoming commands
and messages.
I think implementing 0-10 will be a useful context to address some of
these. For one thing I think it will more cleanly demarcate between
'methods' of relevance to the application from those more important to
the lower levels of the implementation.
It is worth stressing also, as Robert Greig has pointed out, that the
more directly the API follows the protocol, the more likely it is to
change with successive versions of the protocol. A good example there is
the transition from 0-8 to 0-9: the change from 'basic' to 'message'
had a bigger impact on code written against the direct python API than
code written against the c++ API.
Let me be very clear that I am *not* in anyway suggesting that this
implies a directly generated API is a bad thing; I am a huge fan of the
python client and want to make the c++ client more consistent with it.
I'm just pointing out that at this stage of the protocols evolution
changes to such APIs are to be expected. Where we want to avoid that
causing problems we could consider providing higher level 'building blocks'.
