git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Petr Baudis <pasky@suse.cz>
To: Jakub Narebski <jnareb@gmail.com>
Cc: Christian Couder <chriscool@tuxfamily.org>,
	git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
	Sverre Rabbelier <srabbelier@gmail.com>,
	Shawn O Pearce <spearce@spearce.org>,
	Scott Chacon <schacon@gmail.com>,
	Pavan Kumar Sunkara <pavan.sss1991@gmail.com>,
	Sam Vilain <sam@vilain.net>,
	catalyst@lists.scsys.co.uk
Subject: Re: GSoC 2010: "Integrated Web Client for git" proposal
Date: Sun, 18 Apr 2010 02:59:17 +0200	[thread overview]
Message-ID: <20100418005917.GO10939@machine.or.cz> (raw)
In-Reply-To: <201004180246.18263.jnareb@gmail.com>

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.

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

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

-- 
				Petr "Pasky" Baudis
http://pasky.or.cz/ | "Ars longa, vita brevis." -- Hippocrates

  reply	other threads:[~2010-04-18  0:59 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-15  4:30 GSoC 2010: "Integrated Web Client for git" proposal Christian Couder
2010-04-18  0:46 ` Jakub Narebski
2010-04-18  0:59   ` Petr Baudis [this message]
2010-04-18  1:24     ` Jakub Narebski
2010-04-18  2:12       ` Petr Baudis
2010-04-18  8:52         ` Pavan Kumar Sunkara
2010-04-18 21:22           ` Jakub Narebski
     [not found]             ` <w2pe72faaa81004182334xd6fc56d7o31420ca4af867cc2@mail.gmail.com>
2010-04-19  6:35               ` Pavan Kumar Sunkara
2010-04-19 17:00               ` Jakub Narebski
2010-04-19 17:55                 ` Pavan Kumar Sunkara
2010-04-19 23:14                   ` Jakub Narebski
2010-04-20 12:17                     ` Pavan Kumar Sunkara
2010-04-18 22:31           ` Petr Baudis
2010-04-19  6:46             ` Pavan Kumar Sunkara
2010-04-19  6:50               ` Matthieu Moy
2010-04-19  7:23                 ` Junio C Hamano
2010-04-19  7:38                   ` Pavan Kumar Sunkara
2010-04-19  9:07                     ` Petr Baudis
2010-04-19 12:27                       ` Matthieu Moy
2010-04-19 12:57                         ` Pavan Kumar Sunkara
2010-04-19 13:14                           ` Matthieu Moy
2010-04-19 11:57               ` Petr Baudis
2010-04-19 18:10                 ` Pavan Kumar Sunkara
2010-04-20 11:47                   ` Petr Baudis
2010-04-18 17:50         ` Jakub Narebski
2010-04-18 19:56           ` Petr Baudis
2010-04-19 10:43             ` Jakub Narebski
2010-04-19 11:51               ` Petr Baudis
2010-04-19 18:03                 ` Pavan Kumar Sunkara
2010-04-20 12:07                   ` Petr Baudis
2010-04-20 18:14                 ` Jakub Narebski
2010-04-21 20:49                   ` Pavan Kumar Sunkara
2010-04-22 20:25                     ` Petr Baudis
2010-04-22 21:15                       ` Junio C Hamano
2010-04-23  7:10                         ` Petr Baudis
2010-04-23  9:44                           ` Junio C Hamano
2010-04-22 21:53                       ` Pavan Kumar Sunkara
2010-04-23  5:27                     ` Christian Couder
2010-04-23  5:42                       ` Pavan Kumar Sunkara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100418005917.GO10939@machine.or.cz \
    --to=pasky@suse.cz \
    --cc=catalyst@lists.scsys.co.uk \
    --cc=chriscool@tuxfamily.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jnareb@gmail.com \
    --cc=pavan.sss1991@gmail.com \
    --cc=sam@vilain.net \
    --cc=schacon@gmail.com \
    --cc=spearce@spearce.org \
    --cc=srabbelier@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).