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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html