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

[Taisuke Yamada]

Hi Shigio,

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

Yes, what to achieve is the primary topic.
We just need minimal flexibility to support that.

Feature-wise, I'd like to achieve following:

1. Better support for server-less execution,
   as a by-product of improved HTTP proxy compatibility.

   From this fix, you will gain following:

     a. Improved support for access over HTTP proxy.
     --- and, "as a by-product" ---
     b. Faster setup time   - good for ad-hoc hacking
     c. Less administration - helps when you are not an admin
     d. Stronger security   - no server means less sercurity concern
     e. Faster response

   I know you aren't positive with browser-specific fix, but
   it is not. Although my focus is on enchancement #b/c/d/e,
   it also fixes issue #a in a general way.

# I'm omitting technical detail so we can focus on each value.

2. Generate custom HTML.

   Just as an example, I have a script using global that generates
   output similar to "grep -A 10 -B 2". This prints lines before/after
   matching pattern, and gives me better overview of caller/callee code.
   It'd be nice to have this in HTML interface as well.

   I think other people have their own favorite style of viewing,
   so I'm not asking to include above interface. Instead, I propose
   to add a hook to generate custom HTML.

With certain wrapper code, both can be done now - though not with ease.
But with certain modification, these are fairly easy to support.
Making these easier by default, I think, adds value to global.

Also, as Ron pointed out, instead of generating global.cgi everytime,
having only one copy is nice (maintenance-wise). But that also means
everyone will be affected when you customize that single copy. To avoid
that, it's better to make some part run-time overridable with external
configuration.

Best Regards,

> 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