Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (nike.apache.org: domain of gsim@redhat.com designates
 209.132.183.28 as permitted sender)
Message-ID: <4E4C0A42.5040401@redhat.com>
Date: Wed, 17 Aug 2011 19:36:50 +0100
From: Gordon Sim <gsim@redhat.com>
Organization: Red Hat UK Ltd, Registered in England and Wales under Company
 Registration No. 3798903, Directors: Michael Cunningham (USA), Mark Hegarty
 (Ireland), Matt Parsons (USA), Charlie Peters (USA)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b1
 Thunderbird/3.0.10
MIME-Version: 1.0
To: users@qpid.apache.org
Subject: Re: Sender name vs address (C++ messaging API)
References: <4E4A89CB.3020505@pgs.com> <4E4A9532.4010103@redhat.com>
 <4E4B6365.1030805@pgs.com>
In-Reply-To: <4E4B6365.1030805@pgs.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 08/17/2011 07:44 AM, Toralf Lund wrote:
> Gordon Sim wrote:
>> On 08/16/2011 04:16 PM, Toralf Lund wrote:
>>> The QPid "messaging" API will allow me to create a sender by address,
>>> but (only) look up existing senders by name - the
>>> qpid::messaging::Session class has:
>>>
>>> Sender createSender(const Address &address);
>>> Sender createSender(const std::string &address);
>>> Sender getSender(const std::string &name);
>>>
>>> Can I make *any* assumptions about the name given an address? Is there a
>>> way to look up a sender created earlier for an address? Or isn't this
>>> supposed to be possible? In that case, what exactly is getSender() for?
>>> I mean, I'm assuming name is given by Sender::getName(), but requiring a
>>> Sender to allow the lookup sort of defeats the purpose of the whole
>>> method. OK, you can could maintain an address-to-name map, but then it's
>>> probably easier to store the Sender objects.
>>>
>>> It seems like the name is quite simply identical to the address if
>>> something simple like a queue name was passed on create, but I suspect
>>> it's not quite that simple for more complex addresses...
>>
>> At present the C++ client will use the address name as the name for
>> the sender or receiver where it can do so without ambiguity.
>>
>> If you create two senders (or two receivers) for the same address,
>> then the second will have a numeric suffix added to the name to
>> distinguish them.
>>
>> So e.g.
>>
>> Sender s1 = ssn.createSender("my-node");
>> Sender s2 = ssn.createSender("my-node/my-subject");
>>
>> would result in s1 having name 'my-node', but s2 having name 'my-node_2'.
> OK.
>> I would like to augment the logic to use the link name instead of the
>> node name if explicitly specified in order to give more control where
>> that is needed. Does that sound useful to you?
> Uh, I must admit it is not entirely clear to me what a link name might
> represent, but maybe...

A 'link' is the logical association between a sender or receiver and 
their target or source respectively. It a pathway along which messages 
travel to or from some 'node'.

> What I'm looking for is a clear and consistent
> way to distinguish senders in a case rather your example above, only I'd
> use something more like:
>
> Sender s1 = ssn.createSender("my-node/my-subject");
> Sender s2 = ssn.createSender("my-node/some-other-subject");
>
> using 'my-node' and 'my-node_2' for addressing might work, but is
> obviously not ideal. Specifying an additional id of some kind would
> probably be OK.

My initial thought was to use the link name. However on reflection that 
isn't really ideal either.

What you really want is a way to give the senders a name of your own 
choosing *independent* of the address used (likewise for receivers).

So either an overloaded createSender()/createReceiver() method that 
additionally took a name to use and/or a Sender::setName() to alter the 
name once you have created the sender. I think I prefer the former.

>
> Not that I'm sure I'll set up the senders that way in the final
> application - this is prototyping...
>
> - Toralf
>
>
>
> This e-mail, including any attachments and response string, may contain
> proprietary information which is confidential and may be legally
> privileged. It is for the intended recipient only. If you are not the
> intended recipient or transmission error has misdirected this e-mail,
> please notify the author by return e-mail and delete this message and
> any attachment immediately. If you are not the intended recipient you
> must not use, disclose, distribute, forward, copy, print or rely on this
> e-mail in any way except as permitted by the author.
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org