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

[Jakub Narebski <jnareb@gmail.com>]

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

> > 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?)?
 
> > 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. 

> > 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