qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Subject Re: Use of subject for routing - moved thread to user list from earlier private discussion.
Date Fri, 29 Aug 2014 15:57:47 GMT
On 29 August 2014 17:39, Gordon Sim <gsim@redhat.com> wrote:

> On 08/29/2014 03:42 PM, Rob Godfrey wrote:
>
>> The to field indicates the destination in terms of what the sender wants
>> to
>> send it to.  It says nothing about where it actually arrives.
>>
>
>     "The to field identifies the node that is the intended
>      destination of the message. On any given transfer this
>      might not be the node at the receiving end of the link."
>
>
>     "Examples of AMQP nodes are producers, consumers, and
>      queues."
>
> I can certainly see that it is useful to 'redirect' messages, i.e. to
> deliver them to nodes other than that 'identified' as the 'destination'. I
> can also certainly see that you might want a looser interpretation of the
> to field to be some sort of abstract or logical description of 'message
> content and purpose' rather than the identity of a specific node.


> I'm not opposed to change. However I don't think the use of subject for
> what might be termed 'routing' is obviously wrong or unintended by the
> current spec and therefore an illogical choice for anything 'designed
> around AMQP 1.0'.
>
>
I'm not saying it's wrong... And indeed originally I was very much of the
opinion that subject was a surrogate for the routing-key in 0.10 (which is
why I originally implemented filters in that way).


> As an example let's take a simple news service. Senders send in some news,
> recipients subscribe to receive news. Messages are classified with regard
> to the type of news, e.g. sports, weather, politics whatever.
>
> In such a case I think it would be a perfectly understandable choice given
> the current spec to specify the type of news, the classification, in the
> subject. It is after all clearly indicating in a brief way the content and
> purpose of the news.
>
>
Absolutely, though you could also envisage a scenario where there were
other dimensions to the message (such as the geographical location)... and
a user might only want to subscribe to say women's football sport news in
Malmo, (Sweden, Europe).  I think subject's utility as such a field is
really dependent on how easily it is surfaced in various APIs.


> The c++ broker uses the subject when routing through pre 1.0 style
> exchanges because that's what the only document on the subject - namely the
> legacy filters, defined 'to allow a consistent mechanism for addressing
> legacy AMQP Exchanges over AMQP 1.0' - specifies.
>
> There may be good reasons to change this and reinterpret the property
> descriptions. I don't think the wording of the current specification is one
> of them.
>
>
>
As previously stated - the change to the behaviour of the existing
exchanges in the Java Broker was unintentional, and I'm happy to restore
(as soon as I can figure out how without breaking the ability to use things
like the AMQP management node from 0-9-1).  However I think the potentially
more contentious question is actually message translation.  Behaviour of
exchanges can be considered a property of a given exchange/node/address
whatever you want to call it.  Message translation is externally visible
and obviously we should be striving to have commonality there. Given an
AMQP 1.0 message how does one translate that into an AMQP 0-9-1 or 0-10
message (along with their associated delivery headers).  In particular for
reply to... I am translating an AMQP 0-10 exchange + routing-key combo into
and AMQP 1.0 address of "exchange/routing-key" ... How does the C++ broker
translate the replyTo address?

-- Rob


> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message