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:

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


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

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