> Hi, Alexis here from RabbitMQ.
>
> One way to look at 'push messaging' technologies is to think about
> four different parts:
>
> - messages
> - pubsub
> - queues (and 'hubs')
> - storage
>
> PSHB defines a model for the first two but is somewhat silent on the
> latter two. This will make it difficult to use PSHB for what you want
> ('queues') unless you write some custom code, thereby killing any
> benefit you may get from 'simplicity'.
>
> Let's take a closer look:
>
> On Sat, Feb 6, 2010 at 9:37 AM, Ruka <[email protected]> wrote:
> > Hi All,
> > I'm interested in pshb to be used as a message queue system. Still I'm
> > not sure if this use case is possible. Basically the system I need is
> > a kind of command router - modules which are command servers subscribe
> > to a message type (which is in pshb terminology topic or a feed).
>
> PSHB has a routing model based on *subscriptions* to *topics*.
> Currently topics are publisher-defined URLs for Atom feeds.
>
> (*) Publication occurs by posting content (somewhere) and updating the
> Atom feed. At some point, when content is added to a feed, the hub is
> notified by the publisher that this has occurred.
>
> > A
> > module which initiates a command would be a publisher of a certain
> > message type. As you can see, multiple modules can be publishers of
> > the same message type/topic which is not exactly what pshb is made
> > for?
>
> Currently, only if all modules can do (*) above.
>
> In effect, the feed would then be the queue. The hub would simply
> cache copies of that queue for subscribers, who would 'share' this
> queue and (potentially) consume all messages on it.
>
> I don't think that is what your use case requires. Am I right?
>
> I *think* what you want is a way for publishers to publish messages
> directly to a shared queue (called 'topic') on a hub, from where the
> messages can be round-robined to subscribers. Doing this with PSHB
> would be quite a contortion right now.
>
> > Also in this scenario subscriber comes first, not publisher - so
> > it might be reversed used case to standard publish/subscribe?
>
> > So my question is if Pubsubhubbub would be a good platform for this
> > system? I know about Advanced Message Queuing Protocol which might be
> > exactly what I need, but it's seems to heavy and I really like
> > Pubsubhubbub simplicity and http/rest orientation.
>
> I think AMQP gives you exactly what you need. If you want
> Pubsubhubbub or HTTP/REST for a 'simpler' interface style, then look
> at:
>
> - RabbitHub
> - RestMS
> - or one of the RabbitMQ HTTP interfaces
>
> Separately, you may find XMPP gives you the functionality you want.
A nice summary of the differences between a queue and Pubsubhubbub
style event distribution, thanks. It brings up some things I've been
working on really want a queue. Pubsubhubbub seems most useful in the
lossy append style event scenario. If you are trying to work with
actors that implement state machines it doesn't really work. To make
it work, especially with a push model, events have to put on another
queue as they come in, which seems a little redundant. Other products
exist, like your fine program, but the prospect of large market place
of hubs is very attractive.
