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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
