Re: gnome-help: uris

[David Merrill <david lupercalia net>]

On Sun, Sep 23, 2001 at 07:00:15AM +0800, Malcolm Tredinnick wrote:
> On Sat, Sep 22, 2001 at 12:55:42AM -0400, David Merrill wrote:
> > Back to the uri issue, because it's my only problem left with
> > rendering all ScrollServer documentation properly, including internal
> > links.
> > 
> > The problem is that if you're not in the Gnome Help Browser, uris like
> > gnome-help: just don't work. They never get fed down to the http
> > server. So the Gnome-specific uri won't work. It has to start with
> > http:// and go from there.
> > 
> > I could work around this by just hacking the xsl stylesheets so that
> > gnome-help gets converted to http://gnome-help/ but do you think
> > that's a good solution? It's awfully kludgy. The clean solution is a
> > standard uri scheme for us all to use. We all have to be able to parse
> > the documentation that's installed in ScrollKeeper.
> 
> I think doing the rewrite as it passes through ScrollServer is the right
> thing to do.
> 
> My view is that all the documents are in XML and need to be parsed by
> the help system before vieing. Something like ScrollServer provides a
> means for converting the DocBook XML into "pure" HTML for viewing in any
> web browser. Since web browsers only handle a few different schemes in
> URIs and you can count on them knowing about "http://";, you are using
> that.
> 
> 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.

> 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. :-)

> > On Mon, Sep 10, 2001 at 12:14:31AM -0500, Dan Mueth wrote:
> > > At any rate, this points to a more fundamental problem with how we are
> > > doing things.  We have cooked up our own half-baked way of resolving URI's
> > > which will be a pain for KDE or anybody else to be compatible with.  KDE
> > > is using some other system.  We really need to come up with a URI scheme
> > > which can be shared with other projects to improve compatibility and make
> > > our lives simpler.  I suspect ScrollKeeper may be useful here.  I think we
> > > really need somebody with some spare cycles to focus on this problem a
> > > bit.
> 
> I never responded to this bit at the time, but since it's still kicking
> around: I disagree. We are using valid URIs and the proposed scheme (as
> outlined in jrb's "undelivered mail" thread) made sense. What we have to
> do is document it clearly so that if any other application wants to be
> able to parse ghelp://... style URIs they can look at a document and
> know unambiguously how to do it.

If that's what I have to do, then I'll do it, but under protest.
Everybody that uses ScrollKeeper is going to be facing this problem,
and the right way to do it is to solve it well, once, instead of doing
it multiple ways. It's bad design, IMNSHO.

Regards,

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