Open Stack

On 07/01/2014 04:14 PM, Alexei Kornienko wrote:
> A lot of driver details leak outside the API and it makes it hard to
> improve driver without changing the API.

I agree that some aspects of specific driver implementations leak into 
the public API for the messaging library as a whole. There are also some 
ambiguities around the intended and actual contracts.

However, I do also think that the existing driver abstraction, while not 
perfect, can be used to implement drivers using quite different approaches.

The current impl_rabbit and impl_qpid drivers may be hard(er) to change, 
but that's not because of the API (in my view).

[...]
> This would allow us to change drivers without touching the API and test
> their performance separately

I think you can do this already. It is true that there are some semantic 
differences when switching drivers, and it would be ideal to minimise 
those (or at least make them more explicit) at some point.

I did some experiments measuring the scalability of rpc calls for 
different drivers - mainly as an initial stress test for the proposed 
AMQP 1.0 driver -which showed significant differences even where the 
same broker was used, just by changing the driver.

I'm not arguing that there will never be a good reason to change either 
the driver API or indeed the public API, but I think a lot can be 
accomplished within the current framework if desired. (With more 
specific changes to APIs then proposed with some context as needed).

--Gordon