qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Godfrey <rob.j.godf...@gmail.com>
Subject Re: Consistent naming convention for JMS client properties (and possibly other clients)
Date Mon, 11 Jan 2010 13:55:16 GMT
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- )

> 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...

> 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:


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...

-- 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message