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

Re: fixhrefgz unnecessary when fixing web-browsers in the correct wayR



> >You can't fix the browsers, because we don't have the source for important  
> >browsers like netscape.
> 
> You mean the Debian Project caving in and changing its standards because
> some non free product cannot be changed? Where is our commitment to free
> software?

We shouldn't be changing the way browsers work.  

Most browsers follow the HTTP/1.0 or 1.1 standard - including Netscape -
and I don't think it's smart to develop a "debian-specific" HTTP
protocol extension -- that's what you are suggesting, in essence.

(or maybe you just mean modifying the behaviour on file:/ URL's - I
 guess there isn't really a defined standard protocol for handling 
 that sort of thing - it's highly browser dependent.  We shouldn't 
 be using that feature if it's so undefined - maybe you want to draft 
 an RFC or a W3C standard? )

I really only see two possible outcomes to this debate:

 1) Store HTML files uncompressed and don't munge the links
       - all web browsers will work, no web server required
       - wasteful of disk space (particularily for large
         documentation packages, like the Java JDK docs,
         or info-style "books") - note that these types of
         documents tend to be monolithic, so they could be
         put into separate optional documentation packages
       - the system administrator could use a compressed
         filesystem like e2compr to conserve disk space
 2) Store HTML files compressed and munge the links with a tool
    like fixhrefgz
       - Lynx and Netscape work with no web server required (I think)
       - other web browsers will work, if they use a web server
         such as boa, or a web server and dwww
       - currently, at least on my system, not a single documentation
         package with .html.gz files has had the links fixed so that
         it works when browsing directly from the filesystem (and I
         maintain two of those packages, oops - even worse the jdk1.1
         docs have compressed and uncompressed files - arrrgh)
       - it's extra work for the developers, and error prone too
       - I think Lars was advocating this, and I was too

Christoph seems to be advocating:

 3) Store HTML files compressed, and don't munge the links
       - Lynx (and others) might work without a web server if they
         were modified
       - Netscape wouldn't work without a web server
       - other web browsers will work, if they use a web server
         such as boa, or a web server and dwww

I was advocating solution #2 - but after looking at the current
state of the documentation - I think I'm going to switch to solution #1 
- storing uncompressed HTML files.  We're not really talking about
a large amount of disk space on the base system, unless the user 
installs documentation packages such as the Java JDK docs.  Plus -
hard disks are cheap - I just bought a 5GB drive for $600 CDN.  And
dwww will probably evolve to make it easy to view the documentation
that is installed on a remote system (on the Internet or via an
Intranet).  Plus, finally, it's the simplest solution.

Cheers,

 - Jim


Attachment: pgpYAFR0MOWSM.pgp
Description: PGP signature


Reply to: