You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2001/09/09 00:35:43 UTC

Re: some Apache questions

From: "Günter Knauf" <ef...@gmx.net>
Sent: Saturday, September 08, 2001 9:03 AM

>>> - the manual doesnt work after build, at least not on Win32 and NetWare.
>>> I have to add always the 'Includes' and 'AddHandler server-parsed .html'
>>> directives. As you know I posted this issue already to the list and
>>> someone
>>> told me that the files will be expanded; but at least with NetWare I'm
>>> 100%
>>> sure that there expands nothing and on Win32 also after 'InstallBin' the
>>> manual isnt functional. I think it would be nice if we add these two
>>> directives to the new directory block of ./manual because then we have
>>> immediatly after a build also a functioning sample for SSI:
>>
>> I disagree.  Please see the expand.pl and notes in 'rolling the release
>> tarball'
>> in the dev.apache.org site.  Users from CVS suffer this same issue.  Users
>> of
>> the tarball/zipfile do not suffer this problem.
>>
>> But the way 1.3 kept the src tree within the build tree is a nightmare. We
>> can't auto-expand without busting the image so it can no longer be updated or
>> committed to cvs.  It's just a tangled mess that is resolved in 2.0
>
> hmm, without having looked yet at 'rolling the release tarball' (but will do!)
> I cant understand why we need a perlscript for expanding (Perl is not on
> every building platform!) when we could have a working manual with only one
> additional and one changed line in httpd.conf on ALL platforms; or do you not
> trust SSI? What is the reason against this idea?

There really is one tarball/zip image for all platforms.  Whoever constructs it
must have perl.

I would accept that (commented out) directives for /manual would be useful with
a tagline "Users of the absolutely current CVS documentation will prefer this;"
so that users who checkout cvs from Apache can enable the directives.  This
could help docco folks as well.

I'd like some other comments about adding to Apache 1.3 (2.0) the following;

<Directory @@ServerRoot@@/htdocs/manual>
    # add the IncludesNoExec keyword to Options below and uncomment the
    # AddHandler {AddOutputFilter} if you check out /manual from CVS
    Options Multiviews
    # AddHandler server-parsed .html   {1.3}

    # AddOutputFilter Includes  .html  {2.0}

Docco folks, you use CVS, would this help?


---------------------------------------------------------------------
To unsubscribe, e-mail: apache-docs-unsubscribe@apache.org
For additional commands, e-mail: apache-docs-help@apache.org


Re: some Apache questions

Posted by Rich Bowen <rb...@rcbowen.com>.
On Sat, 8 Sep 2001, William A. Rowe, Jr. wrote:

> <Directory @@ServerRoot@@/htdocs/manual>
>     # add the IncludesNoExec keyword to Options below and uncomment the
>     # AddHandler {AddOutputFilter} if you check out /manual from CVS
>     Options Multiviews
>     # AddHandler server-parsed .html   {1.3}
>
>     # AddOutputFilter Includes  .html  {2.0}
>
> Docco folks, you use CVS, would this help?

While I think it would probably help, I have two questions about it. One
do we really want to do something in the config file, which tens of
thousands of users will see and not understand (what the heck is CVS?)
in order to make life easier for a handful of users? Two, are'nt we
moving the manual to a separate directory someday anyways. (When is that
happening? Is that happening?) Outside of the htdocs directory. It seems
to make more sense to me, rather than expanding the docs at all, just
putting them in the @@ServerRoot@@/manual directory, and setting up the
various include directives to have them parsed. Is there a reason to not
do this?

-- 
Rich Bowen - rbowen@rcbowen.com
http://www.rcbowen.com/kenya/


---------------------------------------------------------------------
To unsubscribe, e-mail: apache-docs-unsubscribe@apache.org
For additional commands, e-mail: apache-docs-help@apache.org