>
> Given that we cannot control the context in which the client library is
> deployed, I think we need to be flexible in the way in which these
> configuration options can be set. That is I think that it should be
> possible to configure the library by passing in a
> commons.Configurationobject. In that sense for the (Java) client I
> think the decision over XML
> vs YAML vs Properties file etc may be something of a red-herring.
> However I
> am +1 for using XML as the default and as the basis for a common
> configuration style between clients / brokers of all languages.
This is an interesting idea. We could do that for both the broker and the
client, assuming that there's a commons-configuration class which supports
the
user's desired format.
I've no idea what exists in the C++ world (if anything) that gives similar
flexibility... so having a common "QPID" format (in XML) still makes sense
to me. However, certainly for the client I think it is essential we let the
use of the library decide where they source their configuration from (they
themselves may not have much choice).
> A couple of quick questions...
>
> With the Java Client changes, will the client now always require a
> configuration file? [ I hope not :-) ]
The client would only require a config file if you wanted to configure
options
which would require a config file :-) Right now, this would mean SSL, but
it
could mean other options down the road. It should still be possible to get
the
client running without a config file.
Again - I think it is essential that the client can run without
configuration (pretty much as it does now)... we want to make it as easy as
possible to just drop in the appropriate jars and start using, without
having to worry about a myriad of config files (I'm starting to sound like
Alan)
... And at what level are you
> planning to make these options configurable (application instance or
> connection being the two most obvious).
I haven't dug into the client code yet so I can't really say at what level
is
the most practical. Now that we've got the XML/YAML thing put to bed, I'll
be
looking at this shortly. I'd like to add it at the most flexible point
possible
(connection), but that will depend on what the code looks like.
Yes... thinking about it, the most obvious thing is that you look up
connection strings by name (in a config file, through JNDI or whatever).
You also then want to get the configure options for that connection (e.g. if
your connection is called MY_CONNECTION then you might want to get a config
value option by looking up MY_CONNECTION.<config option name> with further
levels of nesting if necessary).
-- Rob
