Gitweb is currently next to largest file (after gitk) in git sources, having more than 235KB, with more than 7,500 lines. Therefore adding any large feature, like gitweb caching by J.H. and my rewrite of it, or "gitweb admin/write" [failed] GSoC 2010 project by Pavan Kumar Sunkara, would require for the new code to be added as a separate module. Otherwise gitweb would fast become unmaintainable. Not in all cases splitting gitweb upfront would be required. If a new feature is clearly separate from the rest of gitweb we can add this new feature as a new module to be used by gitweb. This is for example the case for adding output caching support to gitweb. What must be done however is preparing the infrastructure for modular gitweb sources; to properly test such infrastructure we need at least one gitweb module split off gitweb itself and used by it. This patch series implements this initial step. Note that JavaScript side of gitweb is already split into many smaller files for better maintability (and concatenated on build for better performance) since 9a86dd5 (gitweb: Split JavaScript for maintability, combining on build, 2011-04-28). The major problem with splitting gitweb code into modules (similar to SVN::Web or Gitalist) is its error handling. Currently die_error() subroutine uses non-local jump out of subroutine to end of request. This means however that die_error() must be in the same file as run_request() subroutine, and therefore any module which must use die_error() must include module with run_request()... and one of most natural places for run_request() is a main script. To be able to decouple die_error() and run_request() we have to change the way error handling is done. One approach is to go back to using 'exit' (which ModPerl::Registry redefines to not quit Perl interpreter) in die_error(). But this has serious disadvantages for other persistent environments: FastCGI (with CGI::Fast) and PSGI (emulated via CGI::Emulate::PSGI). It wouldn't either solve problems with handling errors in capturing and caching layer in the future gitweb output caching support. Another solution, used e.g. by SVN::Web, is to handle errors and generate error pages using exceptions. For handling exceptions we would need something like Try::Tiny, for throwing them something like HTTP::Exception (which in turn uses Exception::Class), or HTTP::Throwable... though the latter is probably not so suitable for non-ersistent environments like pure CGI (requires Moose and PSGI). We should probably implement the latter solution... but this patch series doesn't do that. The previous version of this patch series was sent to git mailing list as [PATCHv2 0/2] gitweb: Beginnings of splitting gitweb into modules http://thread.gmane.org/gmane.comp.version-control.git/172659 Shortlog: ~~~~~~~~~ Jakub Narebski (1): gitweb: Prepare for splitting gitweb Pavan Kumar Sunkara (1): gitweb: Create Gitweb::Util module Diffstat: ~~~~~~~~~ gitweb/Makefile | 22 ++- gitweb/gitweb.perl | 401 ++--------------------------------------- gitweb/lib/Gitweb/Util.pm | 438 +++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 472 insertions(+), 389 deletions(-) create mode 100755 gitweb/lib/Gitweb/Util.pm -- 1.7.9 -- 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