Re: jrb's help ideas

[David Merrill <david lupercalia net>]

On Mon, Sep 03, 2001 at 04:38:20PM -0500, Eric Baudais wrote:
> 1) Most people don't have a very good connection to the internet.  This 
> is applicable to many home users in the US and most users in foreign countries.
> I live in Oklahoma and the two biggest cities don't even have good coverage 
> of cable modems or DSL of any sort.  Only by attending college do I have a 
> fast network connection.  Ask Telsa about internet connections in England if 
> you don't believe this.

I am not suggesting a remote help server. I am suggesting a small,
dedicated, and very fast http daemon which supports cgi-like (but not
necessarily actual cgi) flexibility.

This point, as well as all of your additional points, are completely
valid and I agree with you completely. However, they don't apply to
what I am proposing.
 
> 2) Help needs to be local.  This argument goes back to many people not having 
> a good internet connection.  If I want help on a certain application, I expect 
> to click the help button on the application and a window will pop up showing 
> me at least some basic help.  If my network connection is slow, that help 
> could take one minute or more.  This will infuriate users because they are 
> already frustrated with the application and making them wait so long for the 
> help file to be downloaded will make them more angry.

Agreed. Remote help is a great *additional* resource, but not
appropriate for primary help.

> I don't think you understand what we are trying to do with the "help browser."
> The object is to make a browser that is fast and can directly convert and/or 
> display DocBook (the DTD the GDP's help is written in).  Now we have a backend 
> to convert DocBook into HTML.  From that HTML you can use any web browser you 
> wish to display the help.  The problem is the integration of the help files 
> isn't seamless.  What the GDP is trying to do with the "help browser" is to
> make the integration of the help files seemless.
> 
> Nautilus is the only program which integrates the help files seamlessly.  The 
> specification being written is to determine a minimum a web browser needs to 
> integrate the help files seamlessly.  This will hopefully lead to a lightweight
> browser to be modified or created.  A lot of the specification is based on how 
> Nautilus integrates the help files.  The goal is the specification is to 
> encourage other web browsers to integrate GNOME's help files seamlessly.
> 
> The problem with a local help file server is port 80 will need to be opened 
> to listen for requests from the web browser.  This is a huge potential security
> risk.  Many crackers test port 80, among others, for weaknesses.  A help file 
> server provides a potential weakness.  I believe that a good system 
> adminstrator can reduce this risk, but the target GNOME user (newbie with 
> minimum computer knowledge) will not even know a potential security risk 
> exists.

It doesn't need to be, and shouldn't be, port 80. Pick some arbitrary
port. It can specifically reject any nonlocal requests also, so you
don't even need to require proper firewalling.

Anyone that wants to serve help remotely might want to override this,
and that should be possible.

Take a look at the medusa server, http://www.nightmare.com/medusa/ for
an idea of what I'm proposing. I installed it and am tweaking it right
now to see if it would fit the bill, with modifications perhaps. It's
under the Python license, and implemented entirely in Python. You can
catch each request (http://localhost:8080/foo.html) and even handle
man:ls constructs on the fly -- without involving cgi. It is extremely
fast and seems incredibly flexible. Perhaps on further inspection it
won't do what I want to do, but it is the right idea.

I hope within the next week that I can put up a sample site which
serves the scrollkeeper docs on my system, as a proof of concept.

Philosophically, it seems entirely right that the help system should
be powered by a *server*, not compiled by a *client*, and that that
server should be a relatively low level system function, and not
implemented in the gui.

-- 
Dr. David C. Merrill                     http://www.lupercalia.net
Linux Documentation Project                   david lupercalia net
Collection Editor & Coordinator            http://www.linuxdoc.org

Free Dmitry Sklyarov!  http://www.freesklyarov.org
Washington DC Protests http://www.lupercalia.net/dmca