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

[Ron]

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