[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: fixhrefgz - tool for converting anchors to gzipped files

: (Anyeay, even fast machines may be unable to run a web server,
: if they need to be secure. Running extra daemons is insecure.)

Running a web-broser on the machine may also be insecure. If
you run a 8Meg binary on the machine anyways what an issue
could 150K for a webserver be?

: > The big issue here is that you want to change an existing
: > very public API (http protocol) to include compression which

: I'm sorry, but you don't know what you're talking about.

I definitely do.

: When a web browser requests the documentation via HTTP, it
: will be uncompressed by the web server. This already works
: fine. No problem at all.

Yes and I would like to keep it that way. As I understand it you
are proposing to make serving documentation through the webserver
very problematic.

: When a web browser reads the documentation directly from disk,
: it needs to understand how to identify .html.gz as HTML, and how
: to uncompress it, so that it can display it.  This works (except
: for some versions of Netscape, and that might be fixable). The
: only problem is that the documentation contains links to other
: files. The browsers are not (yet?) capable of understanding
: that when the link is to foo.html, and foo.html doesn't exist,
: that they should look for foo.html.gz instead. Because of this,
: the link must be modified to point at foo.html.gz directly.

If you change the links in order to accomodate the Webbrowsers running
on the machine itself then that will change the files that webserver
can sever to the outside world. They are the same files right? Or
is there a separate /usr/doc for html code for webbrowsers running on
the machine?

Which means in turn that the webservers will be forced by the proposed
approach to serve links with .gz suffixes. This is what I object strongly
against because many web-browswers will not be able to handle those suffixes
without special configuration. The user friendliness of the documentation is gone.

: Being able to read documentation directly without running
: a web server is very important.

So far I cannot discern why.

--- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ ---
Please always CC me when replying to posts on mailing lists.

TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .

Reply to: