Re: [PATCH 6/6] GITWEB - Separate defaults from main file

[Jakub Narebski <jnareb@gmail.com>]

On Wed, 16 Dec 2009, Junio C Hamano wrote:

> Not that I am anxious to queue new topics to 'next' right now (we are
> frozen for 1.6.6), but I think having what is proven to work well at a
> real site like k.org is much better than waiting for an unproven
> reimplementation using somebody else's framework only for your theoretical
> cleanliness.  John has better things to do than doing such a rewrite
> himself, and even if you helped the process by producing a competing
> caching scheme based on existing web caching engines, the aggregated
> result (not just the web caching engine you base your work on) needs to
> get a similar field exposure to prove itself that it can scale to the load
> k.org sees, which would be quite a lot of work, no?

I'm not against (well, not much against) custom caching that kernel.org
uses, but I am against large change to gitweb code currently accompanying
caching, namely gather then output solution, which would negatively 
affect performance when caching is turned off.

Also I'd like to have caching code (the one that didn't made it to git
mailing list for some reason, probably vger anti-SPAM filter) cleaned up
for submission: remove commented-out code, reduce code duplication, 
separate dealing with orthogonal issues (cache itself, adaptivity of cache,
background generation and 'in progress' info, generating key for cache
(and improve key generation to include path_info / use %input_params)),
follow the same style that gitweb itself uses.

As for the "[PATCH 6/6] GITWEB - Separate defaults from main file" patch,
it would require modifying gitweb tests to use generated gitweb/gitweb.cgi
rather than source gitweb/gitweb.perl.


As for having caching code tested by git.kernel.org: IIRC there was issue
with it not having cache expiration thus gathering GB of cached data.
-- 
Jakub Narebski
Poland