Robert Godfrey wrote:
2
Yep - I have no concerns about that - thanks!
Now... as to having to use a -D on the JVM to choose which URL format to
use... :-)
-- Rob
are you planning to create more work for me ? :)
We could certainly dynamically figure out which format to use.
Now the question is are we planning to allow both old and new formats
to be used side by side?
Or do we need to make this a configurable policy?
Perhaps that could be done using a -D option?
Something like -Dqpid.dest.format = {URL,Address,Both}
I am happy with either 'Address' or 'Both' being the default .
What do you think?
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
My view is just that we should try to keep things off the command-line / -D
parameters as it makes things harder to use... plus there is no reason why
you might not be mixing old style and new style URLs in the same JVM
(especially if you're running in a container or something like that).
If we can make the syntax unambiguous so that the code can identify which
format it is looking at I think that would be best...
I don't think it's possible to make the syntax unambiguous as you can
have pretty much arbitrary characters in queue names. As I mentioned
before we could have some sort of meta-syntax, e.g. "OLD:..." and
"NEW:..." and we could have a default for addresses that don't start
with "OLD:" or "NEW:", but I don't think there is an easy way to just
look at an unadorned address and figure out which syntax it follows, and
even if this were possible, I think it could possibly be confusing since
you might have very similar looking addresses in both formats, but with
different semantics.
I think this will probably benefit from having the formal grammar for
the new syntax posted, but unfortunately I probably won't get around to
that until sometime well after turkey.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org