[openstack-dev] [marconi] Reconsidering the unified API model

Gordon Sim 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 
case! :-)


More information about the OpenStack-dev mailing list