Hi Taisuke, Shigio! On Fri, Aug 20, 2010 at 07:39:30PM +0900, Taisuke Yamada wrote: > 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.
I think one thing our disagreements about this so far has shown, is that there really is not one correct answer for this, nor is there even an answer that on its own covers all cases as a workable compromise. Security and ease of use have many ways to exclude each other. If we do not cover both, some proportion of users will remain dissatisfied with our answer. > Feature-wise, I'd like to achieve following: > > 1. Better support for server-less execution, I think this is important. I am much less likely today to have a http server running on all my development machines than I was 10 years ago. The main reason for this is that today I pretty much always have good connectivity to one on another machine. So things that need a server I just push across to it. That is both much easier, and more secure than trying to maintain one on every single machine. If global continues to support a "server assisted" mode, then this is a thing we must do well. > 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. 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. 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. If we do not do this, and only provide the simple one, then many people will all try to modify it themselves. It will be much better if all of those people can share that work, and together just make a few good, well audited examples, that cover all the cases that seem important. 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. If we provide a clean separation of the global interface at the correct places, then we can always give people both choices, where one does have an unavoidable conflict with another. Cheers, Ron _______________________________________________ Bug-global mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-global
