httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: [PATCH] ap_add_filter
Date Sun, 20 Aug 2000 20:52:06 GMT

> The problem really seems to be that this sophisticated kind
> of real-time stream filtering is being forced into Apache without
> any kind of concrete goals in mind other than getting rid or
> IOLs and/or BUFF.
> 
> A lot of people reading about it are saying 'that would be neat'
> but I don't see a lot of people outlining specific filtering projects
> that they intend to do ( other than me? ).

Don't take the fact that we aren't talking about the goals to mean we
don't have any.  I have a few modules I would like to write that require
filters.  I also want to allow CGIs to output SSI tags, and make that work
correctly.

> If the primary goal(s) are just to get chunking going under the
> new scheme and add some real-time GZIP IETF Content-Encoding
> support ( since that's the example that keeps being carried through
> all the discussions ) I wonder if the latter is even going to be possible
> given the LICENSING issues which are yet to be resolved.

The primary goals are to get filtering.  chunking is the current example
because it is the only currently working filter.  GZIP is the other
example because it is a filter that is easy to understand.  Again, there
are more goals, but we have to take this one step at a time.

> Is there a plan to resolve how Apache can include or ship
> GNU code or is it assumed that if/when any kind of compression
> filter is added to Apache it will always have to come from a
> 3rd party FTP server and not Apache?

There will never be any GNU code in Apache, unless the GPL changes
substantially.  If nobody else veto's GPL'ed code, then I will.  And, I
expect that plenty of other people on this list would be more than happy
to veto GPL'ed code.  However, we don't need GPL'ed code.  Examples are
just that, examples.  We are using the examples we have because they are
easy to understand, and they seem to demonstrate a minimum that must be
done.

Ryan
_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message