Re: [sca-bindings] ISSUE 12: Usage of JMS selectors

[Eric Johnson <eric@tibco.com>]

I almost certainly need to study this proposal more carefully.

One point did jump out at me from the first glance over it,

Peshev, Peter wrote:
> Updating the proposal as per the Action item : [Peter Peshev] Provide
> detailed write up for Issue 12 now that it has been accepted.
>
> PROPOSAL
[snip]


> *	/binding.jms/@uri - (from binding) URI that identifies the
> destination, connection factory or activation spec, and other properties
> to be used to send/receive the JMS message
> The URI has the following format:
> o	jms:<jms-dest>?
> connectionFactoryName=<Connection-Factory-Name> &
> destinationType={queue|topic}
> deliveryMode=<Delivery-Mode> & 
> timeToLive=<Time-To-Live> &
> priority=<Priority> & 
> selector=<Selector> &
>  <User-Property>=<User-Property-Value> & ...
>   
The URI proposal that the SOAP/JMS group has submitted to the IETF does
not follow this format.
The current version of the proposed spec is here:
http://www.ietf.org/internet-drafts/draft-merrick-jms-iri-00.txt

The URI would instead look something like:
jms:jndi:DestinationName?jndiConnectionFactoryName=____&priority=___...

Several points here:
* Note the arrival of the "variant", in this case "jndi:" added after
the "jms:"
* connectionFactoryName --> jndiConnectionFactoryName
* The proposed URI no longer includes destinationType.
* "selector" would be an extension to the IETF proposal
* I don't think we should mention "user properties" unless we have a
specific plan for them in this specification. The SOAP/JMS specification
notes them because it passes the URI as one of the message properties
for the message carrying a SOAP payload. The destination can then treat
those additional parameters much the same way that an HTTP web service
might interpret additional parameters to an HTTP URL.

-Eric.