I think we both agree that configuration is best. In fact I think you even support environment awareness in configuration system. So, from that perspective we are solid. The rest is just debating personal style and developer freedom. I will answer a few things below, but I think we can close out this thread or take it off-list.
The key thing here is that S2 *suggests* it, it doesn't impose it. My point is that it is fine to suggest it something that the user can alter, but it is bad to do something which alters program behaviour without the environment managers involvement as would be the case with a conditional branch dependant on it's environment. I would also ask the question of "If a developer has seen the framework exihbit a behaviour, are they really a bad citizen for making use of it?".
Suggestions aside, S2 still doesn't make this easy. It needs environment awareness and it should probably default a ton of stuff when in production mode. This one being the top on the list.
I'm also not a fan of just accepting something as good if it's a de- facto standard because I know from experience that not all decisions which make it into the wild are teh right thing to do. Would S1 have been released if WebWork had already been floating around?, Would the Java UI Event model in 1.0 ever had seen the light of day if someone had already started work on what became the 1.1 model?, and you just need to look at the history of EJBs to see things which were de-facto standards which have now been "retired" (Home/Remote interfaces, Message beans that could only get messages from JMS).
Not accepting crap is one thing. Not accepting something that is outside our comfort zone is something else entirely.
To me the big switch idea is like hard wiring your headlights and a speed limiter into your windscreen wipers. Whilst it might seem a good idea, there are situations when you'll just want the wipers on or off.
Haha. Not even sure that's similar enough to the cases I mentioned to make sense. Humorous though.
You may not be happy about it, but a production issue may neccessitate it. My previous message had a real world example of where a database was moved to a smaller system because the performance of many apps was poor due to the total load on the database cluster.
Orbitz was slightly different. No one made environment changes without consulting a developer. We had it happen a few times and it didn't go well because the complexity was too high. It always looked like an acceptable change, but the developers who wrote the code always knew something that others didn't. That's why nearly all of the developers wore pagers and everything was setup to allow developers to help make decisions. Now, that's just Orbitz and I'm certain there are different environments that this would be okay. But I figure call the developer first and double check to see if any flags go up.
In the UK and the US almost all major banks aim to be able to fail over to a DR site within 2 hours for all critical applications, if you add in the requirement for a developer to make a new release for any configuration change that needs to be made you're wasting valuable time.
Yeah, we didn't do releases to change configuration or the environment. It took days to do a release. We just patched things. I know people are feeling a little sick at the thought of ad hoc patching, but it worked for our situation.
But if you dictate behaviour why should your choice change just because the app has changed environment?, if it's a useful feature for you in dev it will most likley be a useful feature to a techie trying to resolve in issue in support, so it should be a configurable switch, not a cast-iron decision that allows you to access features which help you debug the program in dev but provent the techie checking for the source of a problem in production or test .
Might be useful, but in some cases if you turn on cache checking it will crush the entire system. Again, I'm just advocating being pragmatic and protecting the system. However, most cases aren't like Obritz and I could definitely see that leaving cache checking turned on won't impact things too much. But, I'm sorta stuck now and so I do a lot of my work thinking about massive scale up front.
Whilst I repect your position I still hold my view that it will encourage developer lazyness because why would you include code that you know will never run once you've released the application?, in my view thats just unncessary bloat because a developer was too lazy to develop a solution where the code can be removed from the app prior to release.
Fair enough. I still hold that there are a lot of other cases and ways to tackle things.
-bp --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
