You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@attglobal.net> on 2002/09/13 15:11:37 UTC
no doc for MaxMemFree or AddOutputFilterByType
Does anybody have a short description for MaxMemFree?
What about AddOutputFilterByType? Is that working properly now?
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: Review: AddOutputFilterByType
Posted by André Malo <nd...@perlig.de>.
* André Malo wrote:
> * Justin Erenkrantz wrote:
>
>> I don't have any easy solutions to this. Well, I do, but it'd
>> require always doing the ap_getword call in the mainline request
>> path (which is how mod_mime does it). That is so beyond awful...
>
> hmm, now I had the time to think a little bit about. You'll find a
> patch attached for the current function in core.c - untested and just
> meant as idea. Feel free to throw it away, if it's not a good idea...
> ;-)
hmm, I have the feeling, my patches are always overlooked ;-)
Don't wanna be pushy, but is there really nothing to say (e.g. what's
wrong with this or so?)
nd
--
die (eval q-qq:Just Another Perl Hacker
:-)
# André Malo, <http://www.perlig.de/> #
Re: Review: AddOutputFilterByType
Posted by André Malo <nd...@perlig.de>.
* Justin Erenkrantz wrote:
> I don't have any easy solutions to this. Well, I do, but it'd
> require always doing the ap_getword call in the mainline request
> path (which is how mod_mime does it). That is so beyond awful...
hmm, now I had the time to think a little bit about. You'll find a patch
attached for the current function in core.c - untested and just meant as
idea. Feel free to throw it away, if it's not a good idea... ;-)
> Perhaps we should add a:
>
> apr_status_t ap_filter_rec_parse(apr_pool_t *, ap_filter_rec_t **,
> const char *);
No need to define code twice:
+1.
>> - this ordering doesn't affect the DEFLATE and INCLUDES filter
>> (because of different filter types), right?. If so, they are
>> bad examples for the "filter;filter" notation in general.
>> Perhaps this should be mentioned in the mod_mime docs resp. the
>> filters docs, too...
>
> Correct. But, we really only have two user-visible filters that
> aren't experimental. -- justin
Unfortunately. (did my tests with an ExtFilterDefine ;-)
nd
--
If God intended people to be naked, they would be born that way.
-- Oscar Wilde
Re: Review: AddOutputFilterByType
Posted by Justin Erenkrantz <je...@apache.org>.
On Sun, Sep 15, 2002 at 03:16:16AM +0200, André Malo wrote:
> ok, I see the change, but two points:
>
> - AFAICS the filter ordering is still reversed (in contrast to the
> mod_mime definition)?
I don't have any easy solutions to this. Well, I do, but it'd
require always doing the ap_getword call in the mainline request
path (which is how mod_mime does it). That is so beyond awful...
Perhaps we should add a:
apr_status_t ap_filter_rec_parse(apr_pool_t *, ap_filter_rec_t **,
const char *);
which takes a "<filterx>;<filtery>;<filterz>" and appends to the
passed in ap_filter_rec_t (creating one if it isn't NULL). Then,
we can add the ugly code to do insertion at the end of
ap_filter_rec_t in one central place and switch the core and
mod_mime to use this function.
> - this ordering doesn't affect the DEFLATE and INCLUDES filter
> (because of different filter types), right?. If so, they are
> bad examples for the "filter;filter" notation in general.
> Perhaps this should be mentioned in the mod_mime docs resp. the
> filters docs, too...
Correct. But, we really only have two user-visible filters that
aren't experimental. -- justin
Re: Review: AddOutputFilterByType
Posted by André Malo <nd...@perlig.de>.
* Justin Erenkrantz wrote:
> AddOutputFilterByType DEFLATE;INCLUDES text/html
>
> Err, yeah, the code doesn't like that. I'll try to fix that up
> today if I get a chance.
ok, I see the change, but two points:
- AFAICS the filter ordering is still reversed (in contrast to the
mod_mime definition)?
- this ordering doesn't affect the DEFLATE and INCLUDES filter
(because of different filter types), right?. If so, they are
bad examples for the "filter;filter" notation in general.
Perhaps this should be mentioned in the mod_mime docs resp. the
filters docs, too...
nd
--
die (eval q-qq[Just Another Perl Hacker
]
;-)
# André Malo, <http://www.perlig.de/> #
Re: Review: AddOutputFilterByType
Posted by André Malo <nd...@perlig.de>.
* Justin Erenkrantz wrote:
> AddOutputFilterByType DEFLATE;INCLUDES text/html
>
> Err, yeah, the code doesn't like that. I'll try to fix that up
> today if I get a chance.
ok, I see the change, but two points:
- AFAICS the filter ordering is still reversed (in contrast to the
mod_mime definition)?
- this ordering doesn't affect the DEFLATE and INCLUDES filter
(because of different filter types), right?. If so, they are
bad examples for the "filter;filter" notation in general.
Perhaps this should be mentioned in the mod_mime docs resp. the
filters docs, too...
nd
--
die (eval q-qq[Just Another Perl Hacker
]
;-)
# André Malo, <http://www.perlig.de/> #
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Review: AddOutputFilterByType (was: no doc for MaxMemFree or AddOutputFilterByType)
Posted by Justin Erenkrantz <je...@apache.org>.
On Sun, Sep 15, 2002 at 02:08:45AM +0200, André Malo wrote:
> +<p>If you want the content to be processed by more than one filter, you
> +have to use one <directive>AddOutputFilterByType</directive>
> +directive for each of them. Filters of the same type are processed in
> +<strong>reversed</strong> order they appear in your configuration,
> +but see also <a href="../sections.html#mergin">in which order
> +configuration sections are merged</a>.</p>
Hmm, we should be able to support DEFLATE;INCLUDES. For example:
AddOutputFilterByType DEFLATE;INCLUDES text/html
Err, yeah, the code doesn't like that. I'll try to fix that up
today if I get a chance.
Otherwise, +1. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Review: AddOutputFilterByType (was: no doc for MaxMemFree or AddOutputFilterByType)
Posted by Justin Erenkrantz <je...@apache.org>.
On Sun, Sep 15, 2002 at 02:08:45AM +0200, André Malo wrote:
> +<p>If you want the content to be processed by more than one filter, you
> +have to use one <directive>AddOutputFilterByType</directive>
> +directive for each of them. Filters of the same type are processed in
> +<strong>reversed</strong> order they appear in your configuration,
> +but see also <a href="../sections.html#mergin">in which order
> +configuration sections are merged</a>.</p>
Hmm, we should be able to support DEFLATE;INCLUDES. For example:
AddOutputFilterByType DEFLATE;INCLUDES text/html
Err, yeah, the code doesn't like that. I'll try to fix that up
today if I get a chance.
Otherwise, +1. -- justin
Review: AddOutputFilterByType (was: no doc for MaxMemFree or AddOutputFilterByType)
Posted by André Malo <nd...@perlig.de>.
* Jeff Trawick wrote:
> What about AddOutputFilterByType? Is that working properly now?
It works at least for me (win32, 2.0.40 tested).
I've attached a patch for core.xml that should match the current HEAD
(of core.c). Please review and feel free to correct the English if
neccessary ;-)
The patch was reviewed and discussed before with Kess.
nd
--
die (eval q-qq:Just Another Perl Hacker
:-)
# André Malo, <http://www.perlig.de/> #
Review: AddOutputFilterByType (was: no doc for MaxMemFree or AddOutputFilterByType)
Posted by André Malo <nd...@perlig.de>.
* Jeff Trawick wrote:
> What about AddOutputFilterByType? Is that working properly now?
It works at least for me (win32, 2.0.40 tested).
I've attached a patch for core.xml that should match the current HEAD
(of core.c). Please review and feel free to correct the English if
neccessary ;-)
The patch was reviewed and discussed before with Kess.
nd
--
die (eval q-qq:Just Another Perl Hacker
:-)
# Andr� Malo, <http://www.perlig.de/> #
Re: Default build target (was Re: no doc for MaxMemFree or AddOutputFilterByType)
Posted by Astrid Kessler <ke...@kess-net.de>.
Joshua Slive <jo...@slive.ca> wrote:
> Does anyone (particularly people working on translations) have an
> objection to changing the default ant build target to only build "en",
> and have separate targets to build the other languages?
+1
Kess
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Default build target
Posted by André Malo <nd...@perlig.de>.
* Joshua Slive wrote:
> changing the default ant build target to only build "en", and
> have separate targets to build the other languages?
+1.
nd
--
s;.*;aaaaaoaaaoaaaaooooaaoaaaomaaaa:a:alataa:aaoat:a:a:a
maoaa:a:laoata:a:oia:a:o:a:m:a:o:alaoooat:aaool:aaoaa
matooololaaatoto:aaa:o:a:o:m;;s:\s:\::g;y;mailto:;
\40\51/\134\137|ndparker <nd...@perlig.de>;;print;
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Default build target (was Re: no doc for MaxMemFree or
AddOutputFilterByType)
Posted by Joshua Slive <jo...@slive.ca>.
On Sat, 14 Sep 2002, Hiroaki KAWAI wrote:
> No strong objection. +-0 for me.
>
> # IMHO, the default should be 'all.' For the purpose of the kind you
> # mentioned above, we should switch by arguments; like 'build en.'
The reason I am proposing "en" for the default is my continuing crusade to
make sure that the documentation does not become too complicated for the
developers (the people on the dev@httpd list). The more hurdles we throw
in their way (like figuring out the right argument to the build script),
the less likely they are to do proper documentation.
Joshua.
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Default build target (was Re: no doc for MaxMemFree or AddOutputFilterByType)
Posted by Hiroaki KAWAI <ha...@bcl.t.u-tokyo.ac.jp>.
> Does anyone (particularly people working on translations) have an
> objection to changing the default ant build target to only build "en", and
> have separate targets to build the other languages? This would speed up
> the build for most people, and would also prevent people from accidentally
> screwing up work in languages they don't understand.
No strong objection. +-0 for me.
# IMHO, the default should be 'all.' For the purpose of the kind you
# mentioned above, we should switch by arguments; like 'build en.'
Hiroaki Kawai
Department of Complexity Science and Engineering,
The University of Tokyo
http://www.bcl.t.u-tokyo.ac.jp
mailto:hawk@bcl.t.u-tokyo.ac.jp
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Default build target (was Re: no doc for MaxMemFree or AddOutputFilterByType)
Posted by David Shane Holden <dp...@yahoo.com>.
Joshua Slive wrote:
> On 13 Sep 2002, Jeff Trawick wrote:
>
>
>>Joshua Slive <jo...@slive.ca> writes:
>>
>>
>>>In particular, I suggest that you don't even commit the changes
>>>to non-english docs that may occur when you build.
>>>So why don't you regenerate your patch by doing
>>>cd httpd-2.0/docs/manual/mod/
>>>cvs diff *.html.en > docs-patch
>>
>>makes sense... I'll commit the English changes only.
>
>
> Does anyone (particularly people working on translations) have an
> objection to changing the default ant build target to only build "en", and
> have separate targets to build the other languages? This would speed up
> the build for most people, and would also prevent people from accidentally
> screwing up work in languages they don't understand.
>
> Joshua.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
> For additional commands, e-mail: docs-help@httpd.apache.org
>
+1 to separating each language into their own targets.
Shane
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: [PATCH] Re: Default build target
Posted by Erik Abele <er...@codefaktor.de>.
Erik Abele wrote:
> Another point came from an email from Michael Shroepl:
> > I am +1 for the idea as well, and would love to have the
> > target names available being documented in some short "how
> > to build Apache HTML files from XML".
>
> I we're going to commit this, I'm +1 on documenting the new
> language-dependent build-process and even the validation process in some
> (short) way in httpd-site/xdocs/docs-project/translations.xml
>
Ehhh...meant the docsformat.xml page :-)
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
[PATCH] Re: Default build target
Posted by Erik Abele <er...@codefaktor.de>.
Joshua Slive wrote:
>
> Does anyone (particularly people working on translations) have an
> objection to changing the default ant build target to only build
"en", and
> have separate targets to build the other languages? This would speed up
> the build for most people, and would also prevent people from
accidentally
> screwing up work in languages they don't understand.
>
> Joshua.
>
I had a bit spare time and tried to incorporate the proposed additions
to build.xml. See the attached patch. For now 'en' is built as default.
All other languages are invoked by using their abbreviations (de, ja,
pt-br, ru). The validation process remained the same as before.
Additionally I introduced an new target 'all' to get all languages built
at once.
I also added the russian build targets submitted by Ilia Soldis
<s0...@tversu.ru>.
For me everything is working fine, but please test on your own system
with your working language thoroughly before anybody commits this. I
haven't had the time to test every case and I don't want to disturb the
build-process another time :-)
BTW we will have to do a rewrite of the dependsets when all the files
are xml-ized. Up to now only the mod-directory correctly depends on the
stylesheets/language-files.
Another point came from an email from Michael Shroepl:
> I am +1 for the idea as well, and would love to have the
> target names available being documented in some short "how
> to build Apache HTML files from XML".
I we're going to commit this, I'm +1 on documenting the new
language-dependent build-process and even the validation process in some
(short) way in httpd-site/xdocs/docs-project/translations.xml
For any other additions or ideas, please speak up ;-)
Erik
Default build target (was Re: no doc for MaxMemFree or AddOutputFilterByType)
Posted by Joshua Slive <jo...@slive.ca>.
On 13 Sep 2002, Jeff Trawick wrote:
> Joshua Slive <jo...@slive.ca> writes:
>
> > In particular, I suggest that you don't even commit the changes
> > to non-english docs that may occur when you build.
> > So why don't you regenerate your patch by doing
> > cd httpd-2.0/docs/manual/mod/
> > cvs diff *.html.en > docs-patch
>
> makes sense... I'll commit the English changes only.
Does anyone (particularly people working on translations) have an
objection to changing the default ant build target to only build "en", and
have separate targets to build the other languages? This would speed up
the build for most people, and would also prevent people from accidentally
screwing up work in languages they don't understand.
Joshua.
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: no doc for MaxMemFree or AddOutputFilterByType
Posted by Jeff Trawick <tr...@attglobal.net>.
Joshua Slive <jo...@slive.ca> writes:
> In particular, I suggest that you don't even commit the changes
> to non-english docs that may occur when you build.
> So why don't you regenerate your patch by doing
> cd httpd-2.0/docs/manual/mod/
> cvs diff *.html.en > docs-patch
makes sense... I'll commit the English changes only.
> The other thing that should
> be done to cut down on the diffs is to insert some line-breaks in the
> process for generating directives.html (and a few other files).
yessir!
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: no doc for MaxMemFree or AddOutputFilterByType
Posted by Jeff Trawick <tr...@attglobal.net>.
Joshua Slive <jo...@slive.ca> writes:
> In particular, I suggest that you don't even commit the changes
> to non-english docs that may occur when you build.
> So why don't you regenerate your patch by doing
> cd httpd-2.0/docs/manual/mod/
> cvs diff *.html.en > docs-patch
makes sense... I'll commit the English changes only.
> The other thing that should
> be done to cut down on the diffs is to insert some line-breaks in the
> process for generating directives.html (and a few other files).
yessir!
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: no doc for MaxMemFree or AddOutputFilterByType
Posted by Joshua Slive <jo...@slive.ca>.
On 13 Sep 2002, Jeff Trawick wrote:
> "Sander Striker" <st...@apache.org> writes:
>
> > > Does anybody have a short description for MaxMemFree?
> >
> > Sure, I should have documented it in the first place, but hey...
> >
> > MaxMemFree sets the maximum number of free Kbytes that the main
> > allocator is allowed to hold without calling free(). When not
> > set, or set to 0, the threshold will be set to unlimited.
>
> Thanks. I have a docs patch at
>
> http://www.apache.org/~trawick/docs-patch
>
> which I expect to eventually commit. I was a bit alarmed at the scope
> of the changes to the generated html so I intend to get somebody on
> the docs list to review it first (assuming I ever get subscribed :) ).
>
> The patch doesn't update the Japanese version of mpm_common.xml. I
> started to put in the English description of MaxMemFree as a
> placeholder but I wasn't sure what that sort of havoc that would
> create.
>
I think, in general, we should let translators worry about non-english
docs. There are a couple reasons for this: 1) we don't want to mess up
the whole file by opening it in an editor that can't handle the encoding;
and 2) we may eventually have many translations, and we don't want to
place barriers in the way of people trying to update the docs -- I suspect
developers are going to be much less willing to update the docs if they
need to hit 15 or 20 files.
In particular, I suggest that you don't even commit the changes
to non-english docs that may occur when you build.
So why don't you regenerate your patch by doing
cd httpd-2.0/docs/manual/mod/
cvs diff *.html.en > docs-patch
Then the diffs will be much more contained. The other thing that should
be done to cut down on the diffs is to insert some line-breaks in the
process for generating directives.html (and a few other files). At the
moment, that file is essentially one big line, so the diffs are always
huge. But there is nothing you can do about that. It requires a change
to the xsl files.
Joshua.
Re: no doc for MaxMemFree or AddOutputFilterByType
Posted by Joshua Slive <jo...@slive.ca>.
On 13 Sep 2002, Jeff Trawick wrote:
> "Sander Striker" <st...@apache.org> writes:
>
> > > Does anybody have a short description for MaxMemFree?
> >
> > Sure, I should have documented it in the first place, but hey...
> >
> > MaxMemFree sets the maximum number of free Kbytes that the main
> > allocator is allowed to hold without calling free(). When not
> > set, or set to 0, the threshold will be set to unlimited.
>
> Thanks. I have a docs patch at
>
> http://www.apache.org/~trawick/docs-patch
>
> which I expect to eventually commit. I was a bit alarmed at the scope
> of the changes to the generated html so I intend to get somebody on
> the docs list to review it first (assuming I ever get subscribed :) ).
>
> The patch doesn't update the Japanese version of mpm_common.xml. I
> started to put in the English description of MaxMemFree as a
> placeholder but I wasn't sure what that sort of havoc that would
> create.
>
I think, in general, we should let translators worry about non-english
docs. There are a couple reasons for this: 1) we don't want to mess up
the whole file by opening it in an editor that can't handle the encoding;
and 2) we may eventually have many translations, and we don't want to
place barriers in the way of people trying to update the docs -- I suspect
developers are going to be much less willing to update the docs if they
need to hit 15 or 20 files.
In particular, I suggest that you don't even commit the changes
to non-english docs that may occur when you build.
So why don't you regenerate your patch by doing
cd httpd-2.0/docs/manual/mod/
cvs diff *.html.en > docs-patch
Then the diffs will be much more contained. The other thing that should
be done to cut down on the diffs is to insert some line-breaks in the
process for generating directives.html (and a few other files). At the
moment, that file is essentially one big line, so the diffs are always
huge. But there is nothing you can do about that. It requires a change
to the xsl files.
Joshua.
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: no doc for MaxMemFree or AddOutputFilterByType
Posted by Jeff Trawick <tr...@attglobal.net>.
"Sander Striker" <st...@apache.org> writes:
> > Does anybody have a short description for MaxMemFree?
>
> Sure, I should have documented it in the first place, but hey...
>
> MaxMemFree sets the maximum number of free Kbytes that the main
> allocator is allowed to hold without calling free(). When not
> set, or set to 0, the threshold will be set to unlimited.
Thanks. I have a docs patch at
http://www.apache.org/~trawick/docs-patch
which I expect to eventually commit. I was a bit alarmed at the scope
of the changes to the generated html so I intend to get somebody on
the docs list to review it first (assuming I ever get subscribed :) ).
The patch doesn't update the Japanese version of mpm_common.xml. I
started to put in the English description of MaxMemFree as a
placeholder but I wasn't sure what that sort of havoc that would
create.
Have fun,
Jeff
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
RE: no doc for MaxMemFree or AddOutputFilterByType
Posted by Sander Striker <st...@apache.org>.
> From: trawick@rdu74-177-063.nc.rr.com
> [mailto:trawick@rdu74-177-063.nc.rr.com]On Behalf Of Jeff Trawick
> Sent: 13 September 2002 15:12
> Does anybody have a short description for MaxMemFree?
Sure, I should have documented it in the first place, but hey...
MaxMemFree sets the maximum number of free Kbytes that the main
allocator is allowed to hold without calling free(). When not
set, or set to 0, the threshold will be set to unlimited.
Sander