Jakub Narebski wrote:
even if you don't implement two caching API's at least make it
possible to easy change caching backend.
Sure, I'll keep that in mind.
Note also that memcached may not have sense for single machine [...],
and does not make sense for memory starved machines...
For single machines, memcached certainly works fine. For on
memory-starved machines with HD caches, you'd have to cache the
aggregate HTML data, not the data in the backend. So as long as I'm
working on the backend (repository) cache, memcached should be fine.
IIRC the policy usually is that one can install packages
from main (base) repository for Linux distribution used on server,
libcache-memcached-perl is in Debian stable; that's fair enough I think.
Cache::Memcached::Fast doesn't seem to be in Debian as of now, but I
wouldn't worry about performance unless it comes up.
By the way what do you think about adding (as an option) information
about gitweb performance to the [HTML] output,
I'd try to add it when I'd have a bot more of free time
I'd probably wait with this until I've written the Perl Git API.
-- Lea
--
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
