On Mon, Mar 25, 2013 at 3:58 PM, Rafael Schloming <r...@alum.mit.edu> wrote:
> On Mon, Mar 25, 2013 at 3:13 PM, Rajith Attapattu <rajit...@gmail.com>wrote:
>
>> On Mon, Mar 25, 2013 at 2:53 PM, Rafael Schloming <r...@alum.mit.edu>
>> wrote:
>> This is not the case since the time we implemented the addressing stuff.
>> (used to be the case before that).
>>
>> The JMS client behaves the same as the messaging API.
>>
>
> Are you sure? It looks to me like AMQSession.createTopic("foo") will result
> in an address of "amq.topic/foo", and I believe that's what Robbie
> suggested earlier in this thread. This would seem to very much confuse the
> notion of "topic" and "subject" as it is presented in the messaging API.This behaviour was retained to support backwards compatibility as request at the time. You can certainly pass an address string to createTopic() and createQueue() method. > >> >> > (2) Forcing all destinations to be either queues or topics doesn't work >> so >> > well in the AMQP 1.0 world. Going forward we to be able to specify an >> > address that refers to a node that isn't necessarily either a queue or a >> > topic (e.g. it could be a specific kind of service node which doesn't >> > behave like either). I also think it's a valid use case to be able to >> > specify the name of something on the client and not have to know whether >> it >> > is configured on the broker to be a topic or a queue. >> >> JMS does provide the Destination interface, and Queues and Topics are >> indeed special cases. >> >> To provide some historical context, not knowing if it's a Topic or >> Queue has been a general issue in our code base not just for this >> equals issue. >> Hence the suggestions from Robbie and me about specifying a type. >> Our products were heavily geared towards the hub-and-spoke model and >> Queues and Topics are fundamental in this model. >> > > I don't see what the "hub and spoke" model has to do with this at all. > Pretty much every broker already supports things that don't really act like > queues or topics. > > --Rafael --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
