Re: GSOC Proposal.

[Jakub Narebski <jnareb@gmail.com>]

On Tue, 27 Mar 2012, jaseem abid wrote:

> Hello everyone,
> 
> I am interested in participating in GSoC 2012. I have gone through the
> ideas page and  mailing list archives by now.  I would like to suggest a
> new approach for the git instaweb rather than just JavaScript rewrite,
> which i believe can improve the overall quality of the software.

First of all, it is _gitweb_ that is git web interface subsystem.
git-instaweb is the name of script that runs gitweb (using available
web server, including apache, lighttpd, webrick and plackup) and by
default also start web browser opening gitweb, for a repository you
are in.  This is important difference.
 
For the rest I'll assume s/instaweb/gitweb/.

Second, the proposed "Use JavaScript library / framework in gitweb"
project has the advantage of being possible to be done in incremental
improvements (even without expanding client-side scripting in gitweb,
i.e. adding new features possible with using JavaScript library),
rather than all-or-nothing complete rewrite.  The potential for failure
is much higher in "rewrite" project.


It is nice that there is a would-be prospective student that proposes
his own blue-sky idea of a project.  The projects listed on

  https://github.com/peff/git/wiki/SoC-2012-Ideas

were meant to be only _example_ ideas.


> Data and presentation are too tightly bound in the current code base of
> gitweb. CSS classes are hard coded in the Perl script and it makes
> further development difficult and is considered to be a bad practice
> generally.

Separation of content and presentation is considered a good practice,
but it would require in my opinion heavy rewrite to use one of existing
Perl web (micro)frameworks[1] rather than pure old CGI.pm and hand-crafted
code plus some templating engine[2].  This is IMVHO too much work to do
in a single Google Summer of Code.

Though rewriting gitweb using Perl web framework / creating new web
interface based on gitweb could be a good GSoC project.  The problem
might be with selecting self contained set of work that can be done
in time available for GSoC.

Also there is advantage in gitweb using only minimal number of non-core
required Perl modules.  There is always Gitalist, a git web interface
written using Catalyst MVC framework (based originally on some old gitweb
code, much extended since).

[1] For example one of modern PSGI-based microframeworks like Dancer
    or Mojolicious.
[2] For example Template::Toolkit, or HTML::Zoom, or Template::Declare.

> Presentable HTML is the only output from gitweb as of now that 
> can't be used by anything other than a browser.

It doesn't make much sense to use in something other than a browser.
_What_ other use do you think about?

YAGNI, and don't overengineer.

> Using Perl to generate raw 
> data in JSON format (XML will also do, but not preferred) and using
> JavaScript to render it in the browser will lead to the separation of the
> application into multiple modules.

NO.  Requiring JavaScript to be able to render gitweb output is totally
out of question.  Especially for intended audience, which is composed
heavily of programmers and hackers, both of which are prone to using text
web browsers and running NoScript-equivalents or just with JavaScript
turned off.

Note also that splitting gitweb into smaller modules would be not easy,
as it will require reworking current "longjump"-based (non-local goto
outside subroutine) error handling into e.g. exception-based one
(e.g. Try::Tiny + HTTP::Exception)... or porting gitweb to web framework
which does that for us.

Anyway using JSON for output and _client side_ JavaScript for generating
(X)HTML and CSS looks like monumentally stupid idea.

> A Perl hacker can improve JSON 
> generating modules someday without bothering what is being done to the data
> after it is generated.

If / when gitweb is properly split into separate modules, this can be
done by generating Perl data structures (OOP or not), rather than going
microkernel-like design of bogging down performance with marshalling
and unmarshalling to and from JSON.

Proper separation of responsibilities and proper API design and improving
contents side can be done independently on presentation side.

> A JavaScript programmer can use this data to do any 
> of the tasks listed efficiently without bothering how it is being
> generated. This potentially opens the project to a wide developer audience
> and most probably much more efficient code. Generating UI in Perl for non
> JavaScript browsers can be implemented as a 3rd module. The languages fit
> in the context very well.

<irony>
Yep, and adding new view, or new feature in an existing view will require
both knowledge of Perl (to get data) and JavaScript + JS library (to show
data).  Wonderfull way of enlarging pool of possible gitweb developers.
</irony>

> I have submitted a detailed proposal on the melange website. Mentors please
> be kind to go through the same.
> 
> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/jaseemabid/1

-- 
Jakub Narebski
Poland