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

Kurt Griffiths kurt.griffiths at rackspace.com
Tue Jun 10 16:27:41 UTC 2014

> What are 'message feeds' in the Marconi context, in more detail? And
>what aspect of them is it that message brokers don't support?

Great question. When I say “feeds” I mean a “feed” in the sense of RSS or
Atom. People do, in fact, use Atom to implement certain messaging
patterns. You can think of Marconi’s current API design as taking the idea
of message syndication and including the SQS-like semantics around
claiming a batch of messages for a period of time, after which the
messages return to the “pool” unless they are deleted in the interim.

I think the crux of the issue is that Marconi follows the REST
architectural style. As such, the client must track the state of where it
is in the queue it is consuming (to keep the server stateless). So, it
must be given some kind of marker, allowing it to page through messages in
the queue. 

Also noteworthy is that simply reading a message does not also delete
it, which affords the pub-sub messaging pattern. One could imagine
taking a More prescriptive approach to pub-sub by introducing some
sort of “exchange” resource, but the REST style generally encourages
working at the level of affordances (not to say we couldn’t stray if
need be; I am describing the API as it stands today).

To my knowledge, this API can’t be mapped directly to AMQP. Perhaps
thereare other types of brokers that can do it?

On 6/10/14, 7:17 AM, "Gordon Sim" <gsim at redhat.com> wrote:

>On 06/09/2014 08:31 PM, Kurt Griffiths wrote:
>> Lately we have been talking about writing drivers for traditional
>> message brokers that will not be able to support the message feeds part
>> of the API.
>Could you elaborate a little on this point? In some sense of the term at
>least, handling message feeds is what 'traditional' message brokers are
>all about. What are 'message feeds' in the Marconi context, in more
>detail? And what aspect of them is it that message brokers don't support?
>> I’ve started to think that having a huge part of the API
>> that may or may not “work”, depending on how Marconi is deployed, is not
>> a good story for users
>I agree, that certainly doesn't sound good.
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org

More information about the OpenStack-dev mailing list