[Conkeror] [PATCH] New module to define webjumps for git repository summaries.

[John J Foerch]

David Kettler <kettler at internode.on.net> writes:
>> Can this go on the Webjumps page of our wiki, perhaps on its own page,
>> since it is long?  
>
> Perhaps.
>
>> Because of the problems you cite and it being "not
>> nice to external servers" I hesitate to add it.
>
> I think I overstated the problem.  The webjump itself is fine, there's
> only a problem with the completer.  The completer is disabled by
> default; it must be explicitly requested for each gitweb site.
>
> For "external" servers, I don't think the completer is useful
> anyway. Fetching the OPML data from the gitweb server is very slow for
> both kernel.org and repo.or.cz.  Both sites have many projects,
> resulting in a long list.  I don't think the completion system is a
> convenient way to choose from that list.  It's probably better to
> visit the repo list page at the site (which is the default alternative
> url) and select the repo with isearch on that page.
>
> For local servers, the problem is of not much consequence.  It may end
> up requesting the OPML data several times, but if the list is not very
> long that doesn't much matter.  At my work, with about ten projects on
> the gitweb server it works great.  Note that once it's got the data,
> it is cached, so subsequent uses of the webjump incur no cost.
>
> I think the right thing is to fix the completer so it always requests
> the OPML data just once.  That should be straightforward enough,
> presumably involving co_call().  I don't understand the coroutine
> interface well enough yet though.
>
> Another thought for external servers; the completion data could be
> cached somewhere (in a preference or something) and be persistent
> across sessions.  That might reduce the cost enough to make it useful.
>
> regards, David.

Hi David,

  How about the following approach?  Shift the burden of downloading the
OPML file to the user, and have them store it in a directory of their
choice, and update it manually when they want.  This would eliminate the
problem of large downloads at inconvenient times, as well as the problem
of storing the opml data in a profile-dependent way.

  gitweb-webjumps.js would define a user variable called, for example,
`gitweb_webjumps_opml_directory'.  Its default value would be null, and
users would be expected to set it to an nsILocalFile object.  (Conkeror
is now using nsILocalFile objects in favor of string paths for things
like this because they are cross-platform safe and provide convenient
methods for adding directories and resolving relative paths.)

  The user would obtain an opml file and put it in that directory, and
then call `define_gitweb_summary_webjump' with the name of the webjump
and the name of the file.  If needed, there could be any kind of utility
to assist users in obtaining the opml file.

  This design is patterned closely after how search-engine.js works with
its opensearch files.

-- 
John Foerch