httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Random Filter Syntax observations...
Date Fri, 07 Sep 2001 00:43:53 GMT
From: "Justin Erenkrantz" <jerenkrantz@ebuilt.com>
Sent: Thursday, September 06, 2001 5:28 PM


> 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?

At this time, no.  Something to ponder.

> > 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...

Correct - therefore things must be straightforward, predictable, and explicable.

> > 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.

Because from context to context you mean to change the server config.  What
works in one Location doesn't work for another, what is good for one directory
isn't good for another.

You need to be able to replace those configs, if these are piled on, after 
a sufficent number, the user won't be able to untangle where that filter
came in to the picture.  I believe Add/Set will prove more generally useful
than the new Insert/(Delete?) directive, but I'm willing to be proven wrong.


> > > "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.

I'm -1 on eliminating Set/AddOutputFilter syntax.  We can suppliment with Insert which 
has the properties you desire.  As for Remove, that's the converse of the mime Add 
directives, so we need a synonym that reflects new Insert directives (Delete?).

AddLanguage doesn't tack on another meaning every time it's redefined in another
context, the meaning is replaced.  Same with the rest of the Add* directives.

> > 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?  =-)

Only a small piece of a big solution :)

> /me ducks and runs

/me lobs an e-built coffee cup



Mime
View raw message