[openstack-dev] [marconi] Reconsidering the unified API model
gsim at redhat.com
Tue Jun 10 12:18:08 UTC 2014
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
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
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
More information about the OpenStack-dev