[rabbitmq-discuss] request for help!

[Rafael Schloming]

Martin Sustrik wrote:
> Hi Rob,
> 
> First of all I would like to define what's MQ and what's DB. It'll be 
> helpful to get the discussion more focused IMO:
> 
> With DB data are long-lived while queries are transient one-off events.
> 
> With MQ data are transient one-off events while queries are stable 
> long-lived entities.

I would use the term filter in this context. Queries can generally do 
more advanced things like joins and sub queries which don't make sense 
in the context of live data feeds. Filtering that is the subset of 
querying that is common to both archived data and live data feeds.

> My suggestion would be to stretch the abstraction of ignoring the 
> internal node state/algorithms to fully cover the node behaviour:
> 
> 1. Node is a named endpoint for links and that's it.
> 
> 2. There's no concept of message being resident on a node.
> 
> 3. There's no message ordering defined. This follows from the above.
> 
> 4. There's no message state machine. This follows from 2.
> 
> 3. There are no destructive/non-destructive links, just "links".
> 
> Adopting the points above would make core specification much cleaner. 
> The burden of defining storage/ordering/routing etc. is left to "broker 
> behaviour" specification.

I believe this is the intention, and I think we're pretty consistent 
about this up until the messaging book where we start using the term 
node in a narrower way. I think we would benefit from introducing some 
terms like "[lossy] repeaters" to define some broad classes of 
specialized nodes and adjust some of the content in the messaging book 
to use those terms instead of talking about nodes in a way that narrows 
the meaning of the term.

I think from there the broker behavior specification could further 
define the specialized behaviors of queues, topics, etc.

--Rafael