Re: Gnome Help Browser

[Alexander Kirillov <kirillov math sunysb edu>]

Sorry for being so slow, I still do not get it. You want *any* browser
to be able to access url's like "info:emacs"? But then, not only you
need to have some kind of server/port that does the
scrollkeeper/man2html magic - that I can understand - but you also
need to instruct each and every browser to query this port when
resolving man or info or ghelp URL's. AFAIK, if you enter "man:grep"
into "location" field of Netscape, it wouldn't know what to do with it
at all - even if there is a "mini-server" on your machine that can
handle this, Netscape wouldn't know about it.

Sasha

On Sun, Aug 19, 2001 at 10:23:09PM -0700, Chris Lyttle wrote:
> On 19 Aug 2001 23:47:58 -0400, David Merrill wrote:
> > On Sun, Aug 19, 2001 at 06:25:47PM -0600, John Fleck wrote:
> > > On Sun, Aug 19, 2001 at 03:31:07PM -0400, David Merrill wrote:
> > > > > 
> > > > > I think Sasha is right here. A help browser needs to understand what
> > > > > do with a "gnome-help:foo", "man:foo" or "info:food" URL, or linking
> > > > > between and among documents will not work. You're right that if we
> > > > > do gnome-db2htl3 right it will output valid html, but the browser
> > > > > still needs the additional ability to know that when it sees a GNOME
> > > > > help-related url it needs to hand it off to the help system.
> > > > 
> > > > I don't see how that follows. Yes, the *system* has to know how to
> > > > translate man:foo, but that doesn't mean the browser has to do it. Why
> > > > can't the browser talk to the library using http post?
> > > > 
> > > 
> > > David, could you explain in more detail what you mean here? I'd love a
> > > system that could use any browser rather than one that has to be
> > > specially designed to handle our various help urls.
> > > 
> > > How would an arbitrary browser that did not know anything about
> > > "gnome-help:foo" or "man:foo" or "info:foo" urls use http post to
> > > access the help system when it saw such a url? Or, alternatively, is
> > > there a different way we could construct our urls so an arbitrary
> > > browser would know, "Hey, this isn't an ordinary http or file url, I'd
> > > better send it off to the help system."
> > 
> > The scrollkeeper system is doing the job of abstracting the
> > documentation into a library. Why not build a layer on top of that
> > that serves the help via http, and then any browser can use it,
> > including a remote browser. It performs format conversions, searching
> > capabilities, etc.
> > 
> > Imagine a company or project (even the GNOME project or the LDP)
> > serving custom help repositories to which you can subscribe. Remember
> > that scrollkeeper will support remote documents in a future release.
> > Mny excellent sources on the net could be indexed and merged
> > seamlessly into your help environment.
> > 
> In my mind this is a much better approach. Many projects now include 
> a mini 'webserver' or such on a particular port number. It would just be necessary
> to code a GNOME-help webserver that uses a certain port for
> communication and tell the browser to query that port for the help
> pages. That way you would only need to worry about having the webserver
> translate the docs into html for the browser and interface with
> scrollkeeper. This would also be useful in that the webserver could
> 'redirect' when necessary to access remote information. All this is
> standard in the webserver world, all we would need to do is make the
> interface to the help docs.
> 
> Chris