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

[Shigio YAMAGUCHI]

Hi,
In general, flexibility is important.
But does the user need flexibility so much?
And does he read a manual about it?
Because I'm impatient, I like to rewrite the CGI template
(/usr/local/share/gtags/global.cgi.tmpl) directly.

Additionally, the architecture which enables users to overwrite
the default behavior tends to make security holes.
So, flexibility alone is not important, I think.

How about discussing what we should achieve rather than discussing
about architectures to achieve something?

> 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.
--
Shigio YAMAGUCHI <address@hidden>
PGP fingerprint: D1CB 0B89 B346 4AB6 5663  C4B6 3CA5 BBB3 57BE DDA3