Re: Splitting gitweb (was: Re: [PATCH 6/8] gitweb: Highlight interesting parts of diff)
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Feb 10, 2012, 22:52 UTC
- Message-ID
- <201202102352.42101.jnareb@gmail.com>
- In-Reply-To
- <20120210183319.2f56ff88@gmail.com>
Michał Kiedrowicz wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
Show 6 quoted lines
> > 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