On Sat, Aug 21, 2010 at 12:43:56PM +0900, Shigio YAMAGUCHI wrote: > Hi, > > I think if we change from having a generated cgi, to having a static > > ready to go script, then we can in fact have more than one of these. > > Almost all of the things that are currently substituted there would > > be better done with CSS today - which really leaves us only the most > > fundamental conflict of simplicity (and obvious security) vs greater > > versatility to deal with. > > Static CGI script is already possible. Since htags generates CSS based > hypertext by default, you can provide static CGI script (and CSS file > if needed).
If htags does this by copying that static file from $(datadir)/htags/ then I think we win the real simplification that we are looking for. It could even have an option to pick from one of several scripts there. The static scripts are much easier to audit and maintain than if they are generated from code that is still being modified. And people can put their own scripts there and have them work the same way that the 'built in' ones do. This sounds good to me. > > We can provide both a very simple script and a more complex one as > > examples, and the user can select whichever they find more appropriate > > to their particular needs. The packages can provide a default config, > > if they use the complex one, which makes it the equivalent of the simple > > and safe one in its initially installed form. > > I agree about the point that many CGI scripts should exist. > However, each script should be released by the author under his > responsibility. > Complex scripts tends to have security holes. Yes, I completely agree that the people who need and use them should be the ones to maintain them. I see there being roughly three sets of scripts: - Default scripts, released with the Global package, and approved by you. - Contributed scripts, that several people have vouched for and use and share the fixes with each other. I would like to see some sort of compilation of these kept under the global GNU project, if not as a part of the global package itself. These I would likely make available in packages for users. The links you suggest would do, but copies of them known to work with particular global releases would be even better. - Random people's scripts. Things that someone just puts up on their blog, with no guarantee they don't make themselves. If people want to use them, they can put these in their $(datadir)/htags/ or so by themselves. We can provide one simple mechanism in global that works for them all, we just need a '--use-cgi = script_name' option or the like, and some defined places to look for them. > > We three cannot guess all the things that people might find useful to > > add to this. But we can provide good examples for them to begin their > > modifications from. And accept the good ideas to further share. > > I think that the specification of a system is what the author should press > it against the users. There is no specification that satisfies everyone. > So, 'good examples' also cannot satisfies everyone. I think we can find a few common patterns that will cover most people's needs, and the people who do not find any of them to quite suit what they need will at least have a starting point in one or the other. But I agree, if people use this, there _will_ be some things in the third set from above. We can ensure there are no known problems with the ones in the second set though -- and if problems are reported and not fixed, then we can take them down from there. We just need to provide the sandbox and then we can pick whatever flowers grow out of it as we please :) This keeps global very simple, and focussed on being a tag system, and moves The CGI Problem out to the people who want to spend time on that. That seems like a step in the right direction to me. Cheers, Ron _______________________________________________ Bug-global mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-global
