help URI schemes [was: Re: gnome-help: uris]
- From: Dan Mueth <d-mueth uchicago edu>
- To: David Merrill <david lupercalia net>
- Cc: gnome-doc-list <gnome-doc-list gnome org>, ScrollKeeper Devel <scrollkeeper-devel lists sourceforge net>
- Subject: help URI schemes [was: Re: gnome-help: uris]
- Date: Wed, 26 Sep 2001 01:59:39 -0500 (CDT)
[cc'ing scrollkeeper-devel, since this is more about scrollkeeper than
On Sat, 22 Sep 2001, David Merrill wrote:
> On Sun, Sep 23, 2001 at 07:00:15AM +0800, Malcolm Tredinnick wrote:
> > Other help browsers and document viewers which are more tightly tied to
> > GNOME will also be able able to parse the DocBook XML and _will_
> > understand the "ghelp://" or "gnome-help://" or whatever-it-is-this-
> > month scheme.
> What benefit do you gain from using gnome-help:// instead of http://?
> I guess I just fail to see any advantage to using a gnome-specific
> url. The whole point of ScrollKeeper was to build a unified and
> consistent database rather than more of the hodgepodge we have today.
> Let's not create more hodgepodge now that we have a chance to do it
> cleanly and standards-based.
I think we need a special URI scheme since we need to effectively separate
the namespace and provide a special resolution system. For example, the
Gnumeric Manual needs to link to the GFDL DocBook doc. However, the GFDL
doc was shipped with gnome-core, so the gnumeric package doesn't know the
path to the GFDL file or its format. The link is done as "ghelp:gfdl" and
then something (right now it is a combination of gnome-libs and gnome-vfs
I believe) resolves the full path to the GFDL file (which may be in SGML,
XML, or HTML BTW), including any target.
> > My understanding is that ScrollKeeper stores meta-information about
> > documents in a non-application-specific fashion. The problem you are
> > running into is that web browsers need to be set up especially to
> > understand a certain type of valid URI. You can handle that (nicely, in
> > my view) with the dynamic rewrite above and leave the ghelp:// reference
> > there for those applications which can handle it differently.
> No, there won't be any applications which can handle it differently.
> We'll all be handling it the same, but we'll also all be handling
> kde's format and regular http:// format as well. So each of us will
> have three blocks of code instead of one. It's extra effort for
> everyone with no benefit to anyone. It's ugly.
> If you can come up with some real benefit of using gnome-help://, then
> we should *all* use that format -- but just help:// please. :-)
I think we have a need for a special help URI scheme. I would also like
to get away from a proliferation of help schemes and come up with a single
(good) help:// scheme which we all share. This would make things simpler
in the long term. We do have to handle a few interesting problems though.
eg: Does "help://cdplayer" give you the GNOME cd player application or the
KDE cd player application, or neither? How do you handle multiple
documents with the same URI (eg. different versions, languages, formats,
etc. of a given document)? How do you handle targets for both HTML and XML
documents at the same time?
I think we can come up with reasonable answers to these questions. Then
it is just a matter of adding a new element or attribute to the OMF and a
bit of code to ScrollKeeper to do the URI resolution.
I'd be particularly interested to hear opinions from the KDE folks.
] [Thread Prev