(I've chopped some of the previous messages from the end for the benefit
of those in digest mode).
I'm coming from the other side of the configuration debate; the side
that says you should have the configuration file which shows whats
happening as opposed to having "intelligent" defaults which hide
configuration options from the deployer/support person.
So, for your class reloading example, if someone takes your framework,
uses it in dev, does something which relies on the class being reloaded,
and when the app is moved into production it suddently doesn't you'll
end up with the person building on your code going "It works for me".
You can't rely on people reading documents, you can't rely on them
knowing a few years down the line what you choice of dev, test, and
production settings were, and therefore knowing what behaviour to expect.
I disagree that there is configuration defined by environment deployment
people but managed by developers. Managers of the environment should be
able to manage the configuration, developers should only have an
advisory role. The product my company produces is running in well over a
hundred different companies, can you imagine the reponse we would get if
we said that we were the only people who could change it's
configuration?, if we had to be involved if their changed their servers,
clustering solution, database, or anything else related to the app?, and
the increase in support work for us because we imposed that rule? we
wouldn't make anywhere near the sales of the product we do. One of the
things companies look for is the solution to the "If the development
company goes bust can we run without them?", and how can they do that if
the development company is the only people who can make changes to
configuration?
You can set some best guess values for things like cache sizes, thread
pools, etc., but the end user should still be able to alter them
hopefully with the advice of a developer. You put disclaimers saying
things like "Altering these values without our involvements is not
advised and may result in an non-working application", but you still
shouldn't stop them doing it. If there is spare techie time and they
want to test a P4 server against a Q6600 server against a virtualised
multi-core machine on a massive multi-CPU box then thats something they
should be able to do without having to call the developer every time
they want to try something new.
This could be a difference in viewpoint that we have based on our
experience (I get the feeling your app is designed for deployment in
environments you t have a fair amount of control over), but for me apps
should never enforce configuration changes on users purely based on what
environment they in, the deployment/support folk should always be able
to change things when neccessary (including dropping down thread pool
sizes if they need to run the app on a less powerful server in an
emergency).
Al.
Brian Pontarelli wrote:
I've written code that uses environment. Of course, I mainly write
frameworks, so it probably makes more sense there, but I have used
environment to dictate code rules. Eager singletons versus on-demand
singletons, class-reloading, etc. I think it breaks down to this
question, "is there a convention that is based on environment where
adding configuration would incur unnecessary overhead?"
Take class-reloading as an example. The answer to the question would
be yes. The convention is that in development reload and in production
don't. You could use a configuration parameter with a default value
that says reload, but then the developer has to remember to add the
configuration for production to turn it off. For me, it often comes
down to being pragmatic about it while reducing configuration whenever
possible. So, I think code still needs access to the environment.
In terms of configuration, it falls out into these rough areas:
- There are configuration that should be defined by environment
deployment folks, like computer names, but managed by developers
(since after-all we are going to be using that configuration). Those
folks should understand where the configuration lives and possibly how
to change it, but not without consulting developers who wrote the code
that uses it.
- There are configuration that should only be managed by developers
and still vary by environment, like cache sizes, thread pools,
heuristics, etc. This shouldn't be touched by anyone else, but support
staff can make recommendations and then developers can implement.
- There are configurations that shouldn't change by environment.
Usually things like security configuration, kill-switches, etc. These
are the same everywhere and you only change them if something goes wrong.
In all cases, the configuration should be changing per environment and
not the code. So, back to the original statements, I think none of
this is really about laziness. I think that's a poor wording. I think
it is really more about application integrity and making the correct
decisions that will ensure the application doesn't get into production
and explode. However, the more ability to manage the better. I
personally feel that all frameworks, tools, servers, etc, should be
environment aware. Be nice to have web-development.xml and
web-default.xml. Currently, there are just too many things that need
to be wrapped, adapted and proxied because they don't understand
environment.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
