On Mon, Jan 11, 2010 at 8:55 AM, Robert Godfrey <[email protected]> wrote: > 2010/1/8 Rajith Attapattu <[email protected]> > >> Hi All, >> >> The JMS client does not have a consistent naming convention for system >> properties, connection URL properties or extension properties >> specified in extra arguments sent in AMQP commands. >> Some properties start with "amqj[dot]" while other start with >> "qpid[dot]" and some without any sort of prefix. >> This has led to confusion and sometimes two different properties exist >> for configuring the same parameter. >> We also don't have a single place within the code or within >> documentation that lists all these properties. >> >> Therefore I propose the following. >> >> 1. Name all configuration properties, extension properties and >> connection URL properties starting with "qpid[dot]" >> The c++ client is also following the same strategy. It would be >> great if the rest of the clients follow a similar naming convention as >> well. >> >> > agreed with this for all properties where there is not some explicit AMQP > extension convention (e.g. x- ) Agreed.
> >> 2. We should provide backwards compatibility for the currently >> supported properties with a warning that it will be discontinued after >> two release cycles. >> >> 3. For JMS/Java we could use the ClientProperties.java as a >> place-holder for defining the property names. A similar place should >> exist for the broker side. >> >> > Maybe... Having a class which is just a set of Strings never feels very > appealing to me. Certainly every constant should be defined once and only > once though.. I understand your point. But as you also pointed out, the motivation behind this is to ensure a single place where we have all the definitions rather than all over the place. I am thinking about adding some support to the ClientProperties class to handle the backwards compatibility ..etc. I intend to post a patch for this. > >> 4. Document all properties in one single place >> I plan to add this in the new svn documentation that jonathan is >> putting together. >> A preliminary version could be added in the wiki. >> >> > Sort of related, this is where I started documenting the extensions to AMQP: > > http://cwiki.apache.org/confluence/display/qpid/Qpid+extensions+to+AMQP > > Where we start talking about client options I think we need to be very > careful about defining *what* they are options to... i.e. do they alter only > client internal behaviour... or are they something that is passed down the > wire to the broker... etc... Excellent point !! > > -- Rob > >> Regards, >> >> Rajith Attapattu >> Red Hat >> http://rajith.2rlabs.com/ >> >> --------------------------------------------------------------------- >> Apache Qpid - AMQP Messaging Implementation >> Project: http://qpid.apache.org >> Use/Interact: mailto:[email protected] >> >> > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
