Tim Funk wrote:
D'oh.

I was tempted to post a patch first and discuss, but since it was only a setZZZ addition and the functionality is exactly the same when the parameter is NOT set - I thought this could go CTR. In light of the recent CTR/RTC discussions - we are still CTR until the vote passes. Likewise - while this is an API change - I guess my expectation on API change was anything that breaks backwards compatibility. (method signature changes) Unless someone subclassed FileDirContext and used the method names in the patch - then no one (user community) would notice.

When I first wrote this, my first pass was to subclass it where I could just call files() but that didn't work due since I still had to change other methods. I'd have to do a more comprehensive change (more risky IMO) to FileDirContext before I'd be able subclass it effectively.

The real use case is where you have uploaded files, or just a bunch of other files sitting in a different location on disk. You need to make them look as part of the current webapp while not having to rely on symlinks. So the feature is "similar" to the Alias directive in apache.

Since you -1 - I'd like to have a technical reason on why to back the patch out. Then I'd be glad to do so or make the appropriate changes. If the reason is - I think its bloat - I'm not sure how to resolve this issue.

The reasons are:
This sort of features reduces portability (= must be included with caution), can cause a lot of hacking (generally not good), and is going to have to get supported (= the capabilities and configuration need some review). None of these are very serious, but it adds up.

It's not a real veto anyway, but no proper review mechanism exists at the moment, and it's hard to integrate feature additions in 6.0.x without prior discussion.

Rémy

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to