Re: Standardizing help paths

[Elliot Lee <sopwith redhat com>]

On Sat, 6 Nov 1999, Miguel de Icaza wrote:

> On the magic "ghelp" url:
> 
> > I've started doing a little bit of work on the Gnome help subsystem. I'd
> > like to come up with a standard way of referring to a help
> > page/entry/whatever. ghelp: is a really bad hack (it's not a protocol,
> > daggone it!).
> 
> The "ghelp:" prefix (or the http, ftp) are not intended to be
> "protocol" selectors, but the beginning of a universal resource
> identifier.

We have had to do too many really bad hacks to handle the ghelp: stuff,
because we have to turn it into a real URL at many different points in the
path from "gnome_help_display()" to the actual display program.

If you look at the RFC, the scheme always specifies access method
(protocol), not location or file type.

But anyways,

> it seems your proposed scheme is just reinventing things that have
> already been invented.

No, things have not been invented to handle specifying an abstract
location in the help. Let's say we continue using ghelp: as a URL prefix
(which is not so bad as long as we centralize the place where we do all
this URL translation, which is not the case currently) - we still have big
problems, because ghelp: is always of the form 'ghelp:appname' or
'ghelp:appname/filename.html#section', which is not going to allow
flexibility in indexing or switching to XML displaying or what have you
(in indexing, for example, we need to be able to be able to find the html
file & section that corresponds to a specific part of the SGML sources,
and vice versa). The easiest way to solve this problem is to use an
abstract addressing method that can be mapped to different content
implementations.

-- Elliot
Do not meddle in the affairs of dragons,
for you are crunchy and good with ketchup.