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 <[email protected]> PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3 _______________________________________________ Bug-global mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-global
