On Tue, 28 Nov 2000, you wrote:
> James A Sutherland wrote:
> >
> > > That's not a vote, it's a veto.
> >
> > Which is even worse: you don't even appear to have considered
> > the issue, yet you are leaping to a conclusion prematurely.
>
> Not so. Regardless of what you may think, I *did* consider the
> issue, and jumped to no premature conclusions. The issue I
> was considering apparently wasn't the one under discussion,
> however.
Whatever your reasoning, a veto was premature. You vetoed an idea you thought
might be under discussion, before asking what was being proposed.
> > There is more to it than that: using a variable for part of header.*'s
> > content implies that it must be .shtml (or use the x-bit kludge...)
>
> It implies that it needs to be server-parsed, not that it be named
> .shtml. And all of the docco .html files are already server-parsed;
> tthat's how the header and footer get included now.
I know the documentation files are server-parsed; right now, header.html
consists of six lines of HTML, not an SSI directive among them. The suggestion
was to replace this with dynamic content incorporating the entire HTML <HEAD>
section, down as far as the <h1> or thereabouts.
Another justification for creating a new header.* file is that the proposed
header was to include a DOCTYPE definition, probably for HTML 4 Transitional.
Blindly including this in every HTML file would be a bad idea, since it
involves a significant change to every file including it.
Chris was suggesting instead creating a new header, migrating the pages
individually to use the new header instead, then deleting the old one.
> > Rewriting the header and footer from a static HTML file to a
> > dynamic SHTML file would seem like justification for adding the
> > header.shtml file as a new file, and deleting the old one once
> > no pages reference it.
>
> I still don't see the point, since the {header,footer}.html files
> are being parsed *right now*. They aren't static.
They are very definitely static. They may well be being parsed, but this is
just a nop. The current header.html is COMPLETELY different from the proposed
replacement in content.
> > Provided you have wget installed, and the docs are available online
> > or on a server on your machine, it's a single command. If that's too
> > much for everyone else, I would be quite happy to do the packaging
> > myself...
>
> Um, I'm talking about packaging the entire Apache distribution,
> not just the docs.
So was I.
> > I have. AFAICS, this is just a matter of replacing expand.pl with
> > a suitable wget invocation, preceded with a cvs update in the
> > appropriate directory. Same number of steps, no expand.pl needed
> > any more.
>
> But wget needed instead. Since you seem to want to drag out
> aphorisms, how about "if it ain't broke, don't waste time fixing
> it."
OK, we'll all go back to running CERN httpd. Functionally speaking, none of the
docs are "broke" - so why "fix" them? Just write-protect the tree and leave the
docs as they are...
> > Advantage: it works.
>
> No points; what we have right now works too.
The point is, it doesn't work as well as the replacement. Improving the docs
is, after all, the whole point of that CVS repository...
> > Putting SSI commands in header.html won't work terribly well ATM.
>
> What makes you say that? It works just fine right now. So I don't
> see any need to change any file names.
Except the current contents of header.html aren't the header we want, or
structured in the way needed. Changing the contents of header.html would break
every page in docs ATM; putting the new header in a new file allows for a
gradual changeover.
James.
