qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajith Attapattu <rajit...@gmail.com>
Subject Re: Consistent naming convention for JMS client properties (and possibly other clients)
Date Mon, 11 Jan 2010 14:17:47 GMT
On Mon, Jan 11, 2010 at 8:55 AM, Robert Godfrey <rob.j.godfrey@gmail.com> wrote:
> 2010/1/8 Rajith Attapattu <rajith77@gmail.com>
>
>> 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:dev-subscribe@qpid.apache.org
>>
>>
>



-- 
Regards,

Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/

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


Mime
View raw message