Re: GSoC idea: adding JavaScript library / framework in gitweb

[Jakub Narebski <jnareb@gmail.com>]

On Tue, 27 Mar 2012, chaitanyaa nalla wrote:

> Dear Jakub,
> 
> I prepared a schedule for gsoc ,please take a look and suggest me in
> case if you feel some tasks couldn't be completed with in indicated
> time .
> 
> Week 1  understanding how the whole gitweb and related server side
> scripts are implemented , their design philosophy , coding standards ,
> documentation standards to maintain the best practise coding
> practices.

I think you need to at least skim the JavaScript part of gitweb code
to be able to create a decent proposal.

> Brainstorming sessions regarding which libraries to use on 
> specific scenarios by keeping many criteria’s in mind and creating an
> abstract design on the additional features  that have to be added.

I think it would be a good idea to propose JavaScript library / framework
to use for client-side scripting in gitweb (jQuery, MooTools, Dojo, YUI),
explaining shortly why this one and not other (popularity, "weight", your
knowledge, etc.).  Though perhaps not commit to said library.

You say "libraries", but I think gitweb should use single JavaScript
library, perhaps with exception of specialized libraries or plugins for
extra stuff like Raphael.js for drawing.

Also here or later there should be time for short discussion about
marrying use of external JavaScript library to gitweb.perl script and
to our build system (gitweb/Makefile).

> Week 2  Improving Javascript browser detection and incremental blame.

Errr... gitweb does not employ browser detection.  Well, at least not
in strict sense; it does employ some feature detection e.g. to create
XmlHttpRequest -- but that is what library is for, it is assumed to do
cross-browser behavior for us.

Anyway improving existing features, and adding new features should be
much later.  The very first thing is to transform existing code (JavaScript
detection, adjusting timezones and incremental blame) from hand written
JavaScript to using JavaScript library, incrementally if possible, and
removing our own mini-library in `gitweb/static/js/lib/`.

[...]
> Week 3 Improving UI of adjusting timezone by deciding which library /
> framework to use on UI.

I don't think timezone select UI needs much improvement.  

Anyway I think that we would either use library, or UI addons for library
(like jQuery UI if you choose jQuery), or plugins for library.

> Week 4 & 5 design and implementation of client side sorting of tables

That should be fairly easy (though I am not sure if "1 week" easy).
This is what "sorttable" does in jQuery and I guess also other libraries
(built-in or via plugin); what needs to be adjusted is replacing or 
overriding (perhaps via onclick handler) links to server-side sorting
by trigger to client-side sorting.  Keeping table zebra-colored might
be a problem, but I think JavaScript libraries solved that already.

> and client side syntax highlighting of the blob view by handling how
> git web splits the output into lines and providing line numbers.

That can be hard, and here there might be question of choosing separate
library for JavaScript-based source highlighting.  There is also a 
question of integrating it with server-side source highlighting (turning
off JS-based if server side already does syntax highlighting, and using
the same CSS).

> Week 6  testing the code robustly on as many browsers as possible
> (with their versions) and documenting the code neatly .

This is a good idea.

> MidTerm Delivarables : Improving javascript browser detection,
> incremental blame,ui of adjusting timezone .Adding client side sorting
> of tables and client side syntax highlighting of blob view .

I would be happy if at midterms you would have existing JavaScript
features ported to JavaScript library, without adding any new features
or extending existing ones.

> Week 7 & 8 Using deferrands or queues in the interactive blame to
> avoid the editing of DOM which happens asynchronously to avoid
> locking

O.K.  You will have to check chosen JavaScript library documentation
for its name for such things; different libraries uses different names
for asynchronous processing helpers.

This might be hard part, but if you think you can do it in week
or two...

> and automatic extending of clickable area for places where the 
> link is constrained to a single cell or of that type.

Nice.  This also means that on server side we can remove link within
link (which does not work in some overly strict web browsers), but
this server-side change doesn't need to be done by you.

> Week 9 & 10 & 11 design and implementation support for graphical
> representation of history in log ,shortlog and history using Raphael
> javascript library, adding UI to compare arbitrary commits in the page
> using commitdiff view similar to MediaWiki page history view and
> creating a side by side diff from unified diff in javascript so that
> switching between unified diff and side by side diff could be handled
> on client side.

O.K., though graphical representation of history might be harder than
that (than allowed 1 week or 2).

Side-by-side diff is just porting from Perl to JavaScript.

> Week 12  documentation , writing a detail report , testing
> exhaustively and checking whether the written code follows the
> characteristics .
> Note: considerable amount of time will be spent each week
> concentrating on design for adding a new feature since its design
> greatly affects many things.

-- 
Jakub Narebski
Poland