Jakub Narebski <jnareb@xxxxxxxxx> writes: > On Sat, 31 May 2008, Lea Wiemann wrote: > ... >> 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. > > This assumes that command parsing used by gitweb are generic enough > to put them in Git.pm. But some IMVHO are very gitweb-specific, for > example the part in parse_commit_text() beginning with > # remove leading stuff of merges to make the interesting part visible > and the 'age_string*' keys there, parse_difftree_raw_line() which > currently does not support '-z' output, parse_from_to_diffinfo() which > is _very_ gitweb specific, git_get_heads_list() which is not generic > enough (it gets info which gitweb needs, but no more), etc. > >> 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). > > I think it would be better as separate module. Would it be Git::Cache > (or Git::Caching), Gitweb::Cache, or part of gitweb, that would have > to be decided. Besides, I'm not sure if it is really application- > -independent as you say: I think we would get better result if we > collate data first, which is application dependent. Also I think > there is no sense to cache everything: what to cache is again > application dependent. Even though I (for some unknown reason) rarely agree with Jakub on this list, I agree 100% with the above paragraph. In fact I yesterday started to write exactly the same thing but I could not word it well enough, and I am glad Jakub said what I wanted to say in a form that is much clearer than I would have ;-). -- 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
