From: Lea Wiemann <lewiemann@gmail.com>
To: Jakub Narebski <jnareb@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] gitweb: use Git.pm, and use its parse_rev method for git_get_head_hash
Date: Sat, 31 May 2008 14:39:58 +0200 [thread overview]
Message-ID: <4841471E.2070302@gmail.com> (raw)
In-Reply-To: <m3lk1q24nb.fsf@localhost.localdomain>
Jakub Narebski wrote:
> But I'm not sure for example [that] parsing subroutines [that parse the
> output of the git commands should be in Git.pm].
>
> [...] IMVHO caching command output is bad idea. I'd rather have gitweb
> cache _parsed_ data (i.e. Perl structures).
Yes, I agree with you that parsed data should be cached, but for that
reason I think that the subroutine that parse git's output should be in
Git.pm, not in Gitweb:
If you want to cache parsed data, you need the caching layer in between
the application (= Gitweb) and the repository access layer (= command
output parsing), or you would have to insert cache code at every call to
the repository access layer. So you end up with these layers:
(Layer 0: Front-end [HTML] caching.)
Layer 1: Application (Gitweb)
Layer 2: Back-end caching
Layer 3: Repository access (command parsing)
Layer 4: Calls to the git binary
Layer 3 and 4 are application-independent (i.e. not Gitweb specific),
and since they form a usable API, they might as well be written as a
separate API rather than lumped together with Gitweb. Git.pm is a start
of such an API (it does layer 4 and a little bit of layer 3), so it
seems natural for me to extend it.
Layer 2 is application-independent as well, so it can become an extra
class in Git.pm or a separate module. (It should stay independent of
layers 3 and 4).
We may need to have an explicitly implemented layer 0 (front-end
caching) in Gitweb for at least a subset of pages (like project pages),
but we'll see if that's necessary.
> Caching git command output (something like IPC::Cmd::Cached?)
> would only repeat bad I/O patterns of git commands.
I hope you're not assuming that the back-end cache will reside on disk
-- the problem is IO throughput, so having a cache on disk can really
only work for a front-end cache. For the back-end cache, we *will* have
to use a memory cache (or no cache at all).
> P.S. Here it is what could go [from Gitweb] to Git.pm: [snip]
Good points, I agree those should eventually be moved to Git.pm. (They
are not my priority at the moment, since I really want to implement
caching. So unless they move naturally as part of my refactoring, I'll
leave them in Gitweb for now.)
-- Lea
next prev parent reply other threads:[~2008-05-31 12:41 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-30 23:00 [PATCH] gitweb: use Git.pm, and use its parse_rev method for git_get_head_hash Lea Wiemann
2008-05-30 23:03 ` Lea Wiemann
2008-05-31 9:40 ` Jakub Narebski
2008-05-31 12:39 ` Lea Wiemann [this message]
2008-06-01 22:19 ` Jakub Narebski
2008-06-02 5:35 ` Junio C Hamano
2008-06-02 9:29 ` Petr Baudis
2008-06-02 21:32 ` Jakub Narebski
2008-06-02 22:31 ` Lea Wiemann
2008-05-31 13:04 ` Petr Baudis
2008-05-31 14:19 ` [PATCH v2] " Lea Wiemann
2008-05-31 14:34 ` Lea Wiemann
2008-06-01 8:23 ` Junio C Hamano
2008-06-01 15:44 ` Lea Wiemann
2008-06-01 21:33 ` Junio C Hamano
2008-06-01 22:16 ` [PATCH] test-lib.sh: set PERL5LIB instead of GITPERLLIB Lea Wiemann
2008-06-02 5:17 ` Junio C Hamano
2008-06-02 14:08 ` Lea Wiemann
2008-06-02 14:13 ` [PATCH v2] " Lea Wiemann
2008-06-02 20:01 ` Junio C Hamano
2008-06-02 22:19 ` Lea Wiemann
2008-06-03 0:20 ` [PATCH] " Lea Wiemann
2008-06-01 23:18 ` [PATCH v2] gitweb: use Git.pm, and use its parse_rev method for git_get_head_hash Lea Wiemann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4841471E.2070302@gmail.com \
--to=lewiemann@gmail.com \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.