Re: [PATCHv3 3/4 (resent)] gitweb: Optionally add "git" links in project list page

On Tue, 12 Jan 2010, J.H. wrote:

On 01/09/2010 03:20 AM, Jakub Narebski wrote:

quoted

On Sat, 9 Jan 2010, J.H. wrote:

quoted

quoted

I have given some initial thought to converting the $output options I'm
currently using to a print <FH> that Jakub is suggesting & exploring.

It's 'print {$fh}', i.e. use indirect filehandle, not global filehandle.

quoted

I think all told it's going to be a similarly sized patch, since all
output still has to get adjusted (including the things that directly
output but don't print).  

print -> print {$fh} can be separate patch, and it can be checked that
it produces the same results.  Well print -> $output .= could also be
separate patch...

quoted

I'm unsure if there's a real advantage to 
either way, other than design preference. My patch (forcing the output
to get passed around) moves towards more of a modal style design
separating data & layout vs. it's combined nature now, well it's a step
in that direction anyway.

Errr... what?  Forcing buffering (you need to read whole output into
memory, including for snapshots (uncompressed in case of .tar.gz))
is IMVHO orthogonal to the issue of separating data & layout.
BTW. Modern web server interfaces like Rack, PSGI/Plack etc. explicitly
include streaming support.

The inbuilt streaming support does change things, and I don't think it
ultimately changes my caching engine really anyway - I should have that
change done shortly.

It doesn't change caching engine much, especially if you encapsulate this
detail in the caching engine.  With 'print {$fh}' (and in a few places
'printf {$fh}' (!)) you can just do something like:

  $fh = $cache_fh;
  $actions{$action}->();
  show_cached($fh);


About 'should have that change done shortly': I am working now, time 
permitting, on splitting your caching patch in smaller parts, wrapping
it a bit differently (and hopefully more clear).

quoted

The advantage of doing 'print {$fh}' is that $fh can be \*STDOUT, can
be \$buffer, but can be filehandle to (temporary) file on disk, and
you can even "tee" it, i.e. both write to memory/file, and to STDOUT.
The number of possible choices / possible improvements is much larger.

And what is also important it means that people who do not use caching
do not suffer latency penalty and memory pressure from caching 
infrastructure they do not use.

-- 
Jakub Narebski
Poland