Re: Gitweb caching: Google Summer of Code project

[Lea Wiemann <lewiemann@gmail.com>]

Jakub Narebski wrote:
> 1. Caching data
>  * disadvantages:
>    - more CPU
>    - need to serialize and deserialize (parse) data
>    - more complicated

CPU: John told me that so far CPU has *never* been an issue on k.org. 
Unless someone tells me they've had CPU problems, I'll assume that CPU 
is a non-issue until I actually run into it (and then I can optimize the 
particular pieces where CPU is actually an issue).

Serialization: I was planning to use Storable (memcached's Perl API uses 
it transparently I think).  I'm hoping that this'll just solve it.

It's true that it's more complicated.  It'll require quite a bit of 
refactoring, and maybe I'll just back off if I find that it's too hard.

> I'm afraid that implementing kernel.org caching in mainline in
> a generic way would be enough work for a whole GSoC 2008.

I probably won't reimplement the current caching mechanism.  Do you 
think that a solution using memcached is generic enough?  I'll still 
need to add some abstraction layer in the code, but when I'm finished 
the user will either get the normal uncached gitweb, or activate 
memcached caching with some configuration setting.

By the way, I'll be posting about gitweb on this mailing list 
occasionally.  If any of you would like to receive CC's on such 
messages, please let me know, otherwise I'll assume you get them through 
the mailing list.

-- Lea