I'm in complete agreement with Justin on this one.
"Add" says "add" to me. And filters *are* additive.
I wouldn't agree with Joshua's comments about tossing filter directives and
rely on each module to provide their own (how would you order them?), but I
think his meta-comment about "this stuff is confoozled" applies. A step back
and a rethink is probably necessary, rather than poking and prodding at the
various config directives.
Cheers,
-g
On Sun, Sep 02, 2001 at 09:05:50PM -0700, Justin Erenkrantz wrote:
> On Sun, Sep 02, 2001 at 10:49:52PM -0500, William A. Rowe, Jr. wrote:
> > Not this way. No other mod_mime variable behaves the way you you are trying.
> > I'm not kidding about adding a Set{Input|Output}FilterByType/SetHandlerByType
> > so when we ask folks to rely upon mime types, they can actually do so.
>
> And, that's additive?
>
> So, I could do:
>
> SetOutputFilterByType BAR text/*
> SetOutputFilterByType FOO text/plain
>
> As a user, I *expect* that both filters are activated.
>
> I think you make it sound like we have to do:
>
> SetOutputFilterByType BAR text/*
> SetOutputFilterByType BAR;FOO text/plain
>
> Yuck, yuck, yuck, yuck, yuck. (Did I mention I think this is yucky?)
>
> > Yes... please read mod_mime.html. AddSomething is not additive, and can't be.
> > The server config is often a nightmare to grok as things stand today. Don't make
> > things harder by absusing fairly consistant definitions such as AddSomething or
> > SetSomething. The inner container always overrides the outer.
>
> As a user, I expect that to be additive *in the case of a filter*. I
> expect it to override in the other cases - just not this case. You
> can't have multiple handlers, but you can certainly have multiple
> filters.
>
> > So the inner needs AddOutputFilter FOO;BAR html - as of today. I suggested an
> > entire +|- syntax as well, it was somewhat booed since existing +|- syntaxes are
> > perceived as confusing. Here, well I think it's necessary.
>
> That's confusing. I think the cleanest way is for it to be additive
> (with a RemoveOutputFilter to remove one from a higher level -
> ignoring this directive if the filter doesn't exist from a prior
> level).
>
> > None of this is addressing filter ordering across commands yet. I said 8 months
> > ago we've done an inadequte job of defining the use-filters syntax. I'm saying
> > the very same thing today.
>
> Yeah, I expect that the ordering of filter execution isn't going to be
> right given the code we have now. -- justin
--
Greg Stein, http://www.lyra.org/
