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

[Jakub Narebski <jnareb@gmail.com>]

On Tue, 12 Jan 2010, J.H. wrote:
> On 01/09/2010 03:20 AM, Jakub Narebski wrote:
>> On Sat, 9 Jan 2010, J.H. wrote:

>>> 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.
>> 
>>> 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...
>> 
>>> 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).

>> 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