Re: GSoC 2010: "Integrated Web Client for git" proposal

On Sun, Apr 18, Petr Baudis wrote:

On Sun, Apr 18, 2010 at 02:46:16AM +0200, Jakub Narebski wrote:

quoted

Or is it
meant as web analogue of git-gui: a committool, with ability to create
new commits, perhaps to edit files (and add them, delete them, move them
around), a bit like ikiwiki with Git backend, or other Git based wikis
and blogs?

Yes. Though it is probably supposed to be real Git frontend with Git
semantics, not something more abstract with Git under the hood.

Hmmm... doesn't look so easy.  What to do about simultaneous access
(what webmin does?), and working directory (what ikiwiki does?)?
 

quoted

1. Keep "Web Client" separate for gitweb, and make use of gitweb 
   hooks/plugin system like $feature{'actions'}.  This might require
   adding new "hooks" to gitweb.

   The advantage is that "Web Client" can be written in any language,
   not necessary Perl.  The disadvantage that if it is written in Perl,
   some code might be duplicated.  It might be hard to write generic
   hooks - the "Web Client" could be not as well integrated with gitweb.

2. Write "Web Client" as a Perl module, like 'gitweb/cache.pm' in the
   http://repo.or.cz/w/git/jnareb-git.git/log/refs/heads/gitweb/cache-kernel-pu
   and 'require' this file as needed, guarded by global variable or
   %feature.

   The advantage is possible tighter integration.  I am not sure about
   being able to use code from gitweb in "Web Client".  It also requires
   using Perl, and might require using some contortions if the problem
   would be naturally split into multiple modules: there can be multiple
   modules, but it could be better to have them in one file.

I think (2) is only infinitesimally better than (1) if you can't call
all the gitweb methods from your module anyway. For me, the main worry
is maintaining some consistent UI for the user (graphical and URI-wise)
and (2) can accomplish this really only in a limited way unless you go
much further with the modularization first.

Well, you can always add some of "Web Client" functionality directly
to gitweb (for example dispatch must be, I think, in gitweb).  Or you
can (ab)use "do $gitwebgui_pm;" instead of "require $gitwebgui_pm;",
like in http://repo.or.cz/w/git/jnareb-git.git/commitdiff/261b99e3#patch3
(second chunk).

OTOH we can always make gitweb "use Git;" and move some of its routines,
to it after generalization (e.g. config management using single run of
"git config -l -z", unquoting paths, parsing commit/tag/ls-tree/difftree
etc., date parsing and conversion).


BTW. the major thing that prevented me from using Git.pm was the few
places that gitweb uses pipeline, or needs to redirect STDERR to 
/dev/null.  Also t9700-perl-git.sh test doesn't test command_output_pipe
and the like. 

quoted

3. Split Gitweb, add "Web Client" as one of modules.  Might be best
   from the purity point of view, but is practical only if it is
   integrated in gitweb.  That would require getting gitweb maintainer
   out of GSoC.   Also I am not sure how feaible this approach would be.

Would it be really required to get gitweb maintainer out of GSoC in
order to go this way? Why?

Well, at least someone who would be able to manage integrating split
gitweb.  I think that splitting gitweb, and doing it well, is quite
outside this GSoC 2010 proposal: it would be too much. 

-- 
Jakub Narebski
Poland