> 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" <[email protected]> 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. > >--Gordon. > > >_______________________________________________ >OpenStack-dev mailing list >[email protected] >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
