Re: Ideas

On Mon, 4 May 1998, Byron C. Darrah wrote:

> I don't know if I understand this right: Does this suggest replacing
> 0000.html, 0001.html, etc with a single file? If so, then I think that
> might be a mistake. It would require a CGI program to extract each page on
> demand and turn it into HTML. Thus, the extraction/HTML conversion would
> be done each time each message is read, instead of the current way which is
> just once per message. It would mean a much higher system load for busy
> archives.

I agree that *busy* archives probably want to minimize request-time processing. But not-so-busy archives, or archives on beefy servers may not have to worry about it quite as much.

Does anyone have any sense of how much overhead would be involved for on-the-fly generated pages using something like Hypermail's mail-to-HTML engine? If the overhead is small enough compared to other stuff a web server has to do, it might be worth considering making the HTML generation into a request-time thing. At the very least, it could be an option, so that the list administrator could decide whether or not to pre-generate the HTML.

Part of the patch I sent to Kent was a change to make the remaining compile-time settings into config-file settings. It would be even cooler if Hypermail (or a request-time Hypermail CGI utility) could support these options at request time. This would allow *end-users* some control over how they view the archive. Plus, it helps make a distinction between Hypermail's core data set (the mail archive and associated indexes) and the rendered output.

• Jared