httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Re: Random Filter Syntax observations...
Date Fri, 07 Sep 2001 00:28:13 GMT
[ Is it just me or is this message really like 5 or 6?  I reread it
and saw all of the stuff at the bottom. ]

On Thu, Sep 06, 2001 at 12:06:18AM -0700, William A. Rowe, Jr. wrote:
> Push...Filters is a very interesting idea that warrents more consideration,
> especially in terms of subrequests (Push/Pop could be a great idea.)

I'm not sure how you would use Push/Pop filters in this context.  Can 
you provide an example?

> Actually, _many_ filters are going to be better able to cope with their proper
> ordering than a typical Administrator.  If you mean -You-, one of the five 
> gurus of filtering, then yes, it might get in -Your- way.  The average admin
> will be filling the bugs. database, c.i.w.s. forums and every vendor's tech
> support lines with "WHY DOESN'T THIS FILTERING STUFF WORK!?!"

Eh, I disagree.  The ordering should be straightforward enough so that
the typical admin who reads the docs understands.  If it isn't, we've 
got problems in our configuration.  The configuration syntax should
be powerful enough that it is easy for newbies to understand and
is flexible enough that even the project members get confused once
in a while.  =-)  I think we've got a good overall balance of that
in our configuration...

> > > So, I could do:
> > > 
> > > SetOutputFilterByType BAR text/*
> > > SetOutputFilterByType FOO text/plain
> > > 
> > > As a user, I *expect* that both filters are activated.  
> That won't be a problem, rethinking things.
> It will have to go through a wildcard list as a seperate step (before? after?  I don't
> have a good answer).  But using SetOutputFilterByType again for the same text/* or 
> text/plain type in a nested container _will_ override the prior setting.

See, I guess I'm not sure why we are defining that filters must be
the same as other mime properties (which must be single-valued).
It just doesn't make a lot of sense to me to lose the multi-valuedness
(is that a word?) of filters.  Ideally, we should make it very
straightforward to chain filters.  If not, then filters aren't worth
very much, IMHO.

> > > 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.
> As a user?  You aren't a user, you are a project member.  The rest of the world hasn't
> seen filters in Apache.  We have to be very careful here not to confuse the world of
> Unix admins, before they begin perceiving Apache as just as presumptive as IIS.  They
> want to tell the server what to do, not the other way around.

True.  But, I've also played enough with other projects and
configuration to know that we have is downright confusing.  So, if
it confuses me, it'll confuse the rest of the world.

> > > > 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
> > > > 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
> > 
> > I'm in complete agreement with Justin on this one.
> > 
> > "Add" says "add" to me. And filters *are* additive.
> That is _not_ the syntax of mod_mime.  If you use AddCharset in _different_
> containers, the most specific container wins.  That's how all Apache directives work,
> you can't start flipping concepts on administrators.  If you want to add a new 
> directive like Inject or Insert, then fine, but you can't piggy new parsing rules
> on already well-defined and predictable directive families like Set or Add.

Hey, that's even better.  InsertOutputFilter works for me.  It doesn't
have the connotations of the other mod_mime cruft which don't seem to
map well to filters.  +1 on removing SetOutputFilter/AddOutputFilter 
and switching to InsertOutputFilter/RemoveOutputFilter.

> Right on, and that's the thought I wanted to close this message with.
> I'll revert the patch that misused the Add directive.  Now we can go to square one
> and ask what on earth we are asking, exactly.  We don't want to overwhelm the casual
> user of Apache.  We don't want to require a GUI to 'understand' what Apache has done
> to them.

Hey, isn't that what Covalent sells?  =-)

/me ducks and runs

-- justin

View raw message