On 06/10/2014 09:48 AM, Mark McLoughlin wrote:
Perhaps the first point to get super clear on is why drivers for
traditional message brokers are needed. What problems would such drivers
address? Who would the drivers help? Would the Marconi team recommend
using any of those drivers for a production queuing service? Would the
subset of Marconi's API which is implementable by these drivers really
be useful for application developers?
I'd like to understand that in more detail because I worry the Marconi
team is being pushed into adding these drivers without truly believing
they will be useful.
Your questions are all good ones to ask, and I would certainly agree
that doing anything without truly believing it to be useful is not a
recipe for success.
To lay my cards on the table, my background is in message brokers,
however I would certainly not want to appear to be pushing anyone into
anything.
My question (in addition to those above) would be in what way is Marconi
different to 'traditional message brokers' (which after all have been
providing 'a production queuing service' for some time)?
I understand that having HTTP as the protocol used by clients is of
central importance. However many 'traditional message brokers' have
offered that as well. Will Marconi only support HTTP as a transport, or
will it add other protocols as well?
Scalability is another focus as I understand it. There is more than one
dimension to scaling when it comes to messaging however. Can anyone
describe what is unique about the Marconi design with respect to
scalability?
I sincerely hope these question don't sound argumentative, since that is
not my intent. My background may blind me to what is obvious to others,
and my questions may not be helpful. Please ignore them if that is the
case! :-)
--Gordon
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
