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]