Subject: Re: Splitting gitweb (was: Re: [PATCH 6/8] gitweb: Highlight interesting parts of diff)

From: Jakub Narebski <[email-masked]>
Date: Fri, 10 Feb 2012 23:52:41 +0100

Michał Kiedrowicz wrote:
> Jakub Narebski <[email-masked]> wrote:

> > Well, except the fact
> > that I'm rather wary about adding more code to gitweb when it is still
> > single monolithic script, rather than split into packages.
> > 
> 
> Yeah, jumping between 2k'th and 5k'th line isn't a great fun. Do you

There is an easy part, an almost easy part, and a hard part.

The easy part of splitting gitweb is creating infrastructure for it,
at least in the basic case.  The 'gitweb/split' branch in my git forks:

  http://repo.or.cz/w/git/jnareb-git.git
  https://github.com/jnareb/git

contains changes to gitweb and gitweb/Makefile, and splitting off
Gitweb::Util as an example; I'd have to update this branch to current
state of gitweb.

The almost easy part is to come up with a way to split gitweb.  Do we
follow SVN::Web (Subversion web interface in Perl), or maybe Gitalist
(git web interface in Perl, using Catalyst MVC framework)?  Do we use
MVC paradigm?  Or do we split on functionality: diffs, blobs, trees,
logs, etc.?

The hard part is about splitting main parts of gitweb.  It is easy to
put generic subroutines that are not specific to git or gitweb in
Gitweb::Util (or Gitweb::Util::* submodules).  It would be almost as
easy to put parsing of git command output in Gitweb::Parse (or 
Gitweb::Parse::* submodules).

The problem is with putting actual actions in separate submodules.
For that we would need to replace our hacky "longjmp"-based error handling
(nonlocal goto in Perl is roughly equivalent to longjmp() in C) to
exception-based one, as I don't think going back to exit-based error
ahndling is a good idea.  We would need exception-based error handling
if we want to implement HTTP output caching anyway, I think.

Not to not reimplement the wheel, badly, we will do better to use some
non-core Perl modules, namely Try::Tiny for capturing exceptions, and
HTTP::Exception (based on Exception::Class) for throwing exceptions.
So we would have to add a way to handle such non-core modules, perhaps
bundling them with gitweb, like Error is bundled with Git.pm and used
if it is not present on install.

Maybe Module::Install would help us there with bundling of such
dependencies for install; maybe "push @INC, __DIR__.'/inc' would be
a good idea.

It needs thinking about.
-- 
Jakub Narebski
Poland