Re: Bug#590053: global.cgi fails to work with id-utils extension.

[Taisuke Yamada]

Hi.

Excuse me for being unresponsive recently.
Maybe discussion has already ended, but I'll send this anyway...

> cgi doesn't really need to be 'generated' (by htags) at all, just
> the path to @bindir@/global needs substitution and that can be
> done by configure.

I agree. In fact, modified global.cgi I had sent in
(http://lists.gnu.org/archive/html/bug-global/2010-07/msg00006.html)
uses external configuration that allows user to override these
information ($conf->{GLOBAL}).

But going further, to make global.cgi clean and substitution-free,
I think it's worthly to make following overridable (i.e., externally
define-able):

  1. Paths. Not just only "/usr/bin/global", but also for other
     files/folders like HTAGS, HTML/, etc.
  2. URL generator.
  3. HTML generator.

Actually, these are not hard to accomplish. All you need is to

  - Refer to "overridable" parameters/functions through configurable
    variables.
  - Read several locations ("/etc/", "$HOME", and "./" should be
    sufficient) for external config files, and let it override these.

So, for example, let's say you want to have "overridable" URL
generation. All you need is to do something like

  # set default selection in initialization code...
  $conf->{genurl} = \&generate_url;

  # load configuration just before final processing
  for (@external_config_files) { do $_ if $_ }

  # actual content/response generation
  $url = $conf->{genurl}->(...);

and allow user to override "$conf->{genurl}" in case default
one does not fit. By kicking out these to external config files,
on-the-fly generation would be no longer needed.

Maybe we should start discussing on "What should be overridable"
and "What (variable) name to give to make it overridable". Just as
a starter, I'll list names I defined in posted global.cgi:

  $conf->{GLOBAL}    - Path to global.
  $conf->{DOCDIR}    - Name of "HTML/" folder. Used for semi-automated
                       HTAGS_DIR detection.
  $conf->{HTAGS_DIR} - Path to htags-generated content.
  $conf->{HTAGS_URL} - URL to htags-generated content.

I defined them as all of these are sometimes impossible to detect.
For example, URL (HTAGS_URL) detection fails frequently by design - HTTP
specificaion (and implementation) does not let you discover this
perfectly.

Best Regards,

>>> Shigio and I are currently discussing changes to the CGI mechanism
>>> [snip]
>> [RFC] Changing the mechanism of the safe CGI script
>> - http://lists.gnu.org/archive/html/bug-global/2010-06/msg00008.html
>>
>> Assuming it is about above URL, I made several enhancements to
>> global.cgi so it can support wider use-cases.
>
> Yes, that is what we are discussing -- though Shigio pinged me off
> the list about it and didn't keep the list in the cc.  Probably we
> should move that discussion back there again then.
>
>> I'll post it to bug-global@ list so we can discuss detail there.
>
> I'm not currently on that list, so feel free to cc me.  What I'm
> hoping at this stage is that we can simply generate a static cgi
> at build time (which can be effectively audited by the sysadmin),
> rather than have htags generating them on the fly.  That should
> simplify quite a few things about how this operates.  Many of the
> things that are currently substituted by htags in it would probably
> be better handled by a CSS file (which wasn't an option 10 years
> ago, but is a viable one today), in which case the cgi doesn't
> really need to be 'generated' (by htags) at all, just the path to
> @bindir@/global needs substitution and that can be done by configure.
>
> Cheers,
> Ron