httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James A Sutherland <ja...@cam.ac.uk>
Subject Re: HTML3.2 -> HTML4.0
Date Tue, 28 Nov 2000 21:30:33 GMT
On Tue, 28 Nov 2000, you wrote:
> James A Sutherland wrote:
> > 
> > > Putting a burden on the process of packaging the software for
> > > distribution, solely so some files can be renamed.  For this
> > > reason and the effect on the repository, -1.
> > 
> > I never suggested a vote on the issue;
> 
> 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.

> > you actually said that this is already done: "the documentation
> > is packaged as part of the Apache distribution, with the SSIs
> > statically 'compiled'".
> 
> So foo.html looks the same whether you're looking at it on the
> Apache site, a mirror, or your local installation, whether the
> result is being produced with SSIs (the former two) or not (the
> latter).

Is this done, or not? First you said it is done - then one of the reasons you
gave for the veto was that adding this step to building a release would be
unnecessary extra work! Which is it?

> > You've also missed the point completely - "solely so some files can
> > be renamed"?! Renaming some of the files was part of the proposed
> > method, not one of the aims.
> 
> Chris wrote:
> >         Don't know, but if we do the switch by hand, I'd like to use 
> > .shtml or something instead of the .html to make headers & footers 
> > easier to distinguish. This may also make it easier to do the change 
> > over time -- header.shtml can be the newer larger header, and any 
> > hits on header.html in *.html are old files to fix.
> 
> Perhaps I did miss the point.  In which case I don't see what the
> point actually is here.  Chris?

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

> > I don't see what you mean about "the effect on the repository",
> > either: it's a simple change to the HTML files in it.
> 
> Renaming files inside a repository creates headaches.  Lots of
> headaches.  Big ones.  Adding new files, as I now understand
> Chris to be saying, doesn't create headaches, just possibly some
> confusion.

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. This could be regarded as
a rename operation, but it is a case of "rename and replace contents". The
phrase about 30 year old axes on their third handle and fifth head springs to
mind!

> > I accept it involves some extra work in packaging; if the CVS tree
> > were made available, periodically updated, it would be a simple
> > "wget" command to "freeze" the documentation for a release.
> 
> Easily said, since you aren't one of the ones doing the packaging.. :-)

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

> > So put a link to a complete server with the docs on.
> 
> No good.  Lots of installations are done off-net or in intranets
> w/o access.
> 
> > Or "freeze" the docs from a server with SSI enabled.
> 
> That's what's essentially done now, except it isn't done through
> the Web, but by a script.  Take a look at the 'how to roll a release'
> document on dev.apache.org to see how it's currently done.

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.

> In essence, I don't see any advantages here, and some disadvantages
> for people who aren't on the docco project.  But maybe I'm still
> missing the point.

Advantage: it works. Putting SSI commands in header.html won't work terribly
well ATM. The x-bit kludge avoids this, but you're still replacing all the
contents of that file - same axe, new handle, new head...


James.

Mime
View raw message