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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html