* Re: The future of gitweb - part 2: JavaScript
2011-04-14 9:54 ` The future of gitweb - part 2: JavaScript Jakub Narebski
@ 2011-04-14 19:30 ` Michał Łowicki
2011-04-15 1:56 ` david
2011-04-16 17:12 ` Peter Vereshagin
` (3 subsequent siblings)
4 siblings, 1 reply; 30+ messages in thread
From: Michał Łowicki @ 2011-04-14 19:30 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, John Hawley, Kevin Cernekee, Petr Baudis, Petr Baudis
2011/4/14 Jakub Narebski <jnareb@gmail.com>:
>> Now that we are talking about future of git, including breaking some
>> of backwards compatibility bugs / misdesigns for 1.8.0, perhaps it is
>> the time to discuss long term goals and the future of gitweb.
>
> This is second installment, talking about JavaScript (client-side)
> part of gitweb code.
>
> Recently there were sent to git mailing list a new feature which
> further extended use of JavaScript in gitweb, namely adjusting common
> timezone in which dates are shown:
> http://thread.gmane.org/gmane.comp.version-control.git/169384/focus=169881
> http://thread.gmane.org/gmane.comp.version-control.git/171212
>
> It looks like there would be more proposals on (optional) enhancing
> gitweb with JavaScript.
>
> Currently JavaScript is used for the following (optional) features:
> * detecting if javascript is enabled (not a feature per se)
> * incremental blame (Ajax-y, requires server side knowing above)
> * setting local timezone in which dates are shown
>
> Possible other JavaScript-based enhancements include:
> * sorting tables like in Wikipedia, avoiding trip to server
> * MediaWiki-like history view for selecting commits to compare
> (base does not exist yet, and could be used without JavaScript)
>
>
> There was one simple issue that for maintenance and readability it is
> better to have code split into small modules (into separate files),
> while for page performance and interactivity it is better to limit
> number of scripts. This issue can be simply solved by combining
> JavaScript files on build.
>
> There was and is more important issue, namely that in our JavaScript
> we have to abstract or work around differences in web browsers, and
> backport features. This includes:
> * Ajax (generating XmlHttpRequest, handling XHR events)
> * emulating getElementsByClassName if native implementation is absent
> * workaround differences in setting up event handlers by using
> 'elem.onevent = function () { ... }' etc.
> * manipulating stylesheets (CSS)
>
> Those issues are already solved in __JavaScript libraries__ and
> frameworks, probably better way than in our attempt. Using JavaScript
> framework would also give as higher level constructs, and could
> replace what we have and could have in gitweb/static/js/lib:
> * popup menu like the one used to select timezone
> * date parsing and formatting, string formatting
> * handling cookies
>
> Using some JavaScript framework / library could help a lot with
> developing and improving JavaScript part of gitweb code. We would no
> longer need to worry so much on how to do it, but could concentrate on
> what to do.
>
> Unfortunately the decision to use JavaScript framework brings its own
> new problems.
>
> First issue is which JavaScript framework or library to use:
> * jQuery (lightweight, most popular, used e.g. by MediaWiki)
> * MooTools (lightweight, 2nd most popular, opbject-oriented)
> * YUI, The Yahoo! User Interface Library
> * other: Prototype, Dojo, ExtJS, SproutCore,...
>
>
> Second issue is how to use it / how to include it:
>
> * Use some external Content Delivery Network (CDN), like
> Google Libraries API
> http://code.google.com/apis/libraries/devguide.html
> e.g.:
>
> <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.5.2/jquery.min.js"></script>
> <script src="http://code.jquery.com/jquery-1.5.2.min.js"></script>
>
> or
>
> <script src="https://ajax.googleapis.com/ajax/libs/mootools/1.3.1/mootools-yui-compressed.js"></script>
>
> This is nice solution... if we don't need plugin / extension
> which usually are not available in CDN version of library.
>
> Also this makes gitweb dependent on third-party service, and require
> network connectivity to Internet to have access to JavaScript-based
> features.
>
> * Mark appropriate JavaScript library as dependency in gitweb/INSTALL
> to be downloaded in appropriate place but do not provide sources.
> Perhaps add target in gitweb/Makefile that automatically downloads
> it.
>
> This would make installing gitweb correctly more complicated.
> JavaScript-based features would not work if somebody instals gitweb
> incorrectly.
>
> I think we can set up gitweb build so that one can configure at
> build stage whether to use CDN or download library, or use
> pre-downloaded (and perhaps instaled somewhere) version of framework
> (combining JavaScript on build in all but first case).
I'm not sure about pre-downloaded version of libs. Most of the time
it's not a big deal but sometimes it may introduce hard to detect
issues when someone use different version of the lib -
http://ejohn.org/blog/learning-from-twitter/ .But the idea with
options - CDN or download is very good. CDNs can improve the page
download speed by increasing simultaneous connections if files are
downloaded from many hostnames but for companies where instances of
gitweb are on the Intrantet the 2nd option could be better I think (at
least in my case). Additionaly CDNs can save some money when you pay
for data traffic :)
>
> * Provide copy in git sources (in git.git repository), minified or
> development version or both. This would bloat git repository a bit,
> and we would probably want/have to update library at its releases.
>
> jQuery | 24 kB (minified & gzipped), 72 kB (minified),
> MooTools | 25 kB (minified & gzipped), 86 kB (minified)
> YUI | 31 kB (library core only)
> Prototype | 46-278 kB
> Dojo | 28 kB (minified & gzipped), 65 kB (minified)
> ExtJS | 84-502 kB
>
> Some of those, like MooTools[1] and YUI[2], include dependency
> calculator (library builder) where you can get customized version
> with only relevant/required parts included.
>
> [1]: http://mootools.net/core/ and http://mootools.net/more/
> [2]: http://developer.yahoo.com/yui/3/configurator/
>
> Anyway it could be configurable fallback for other methods; this way
> we don't have to keep library up to date.
>
> * Instead of including source code or build (minified) version in git
> repository, we could include JavaScript library as a _submodule_.
>
> This of course is possible only if library in question procides
> source repository, and if it uses Git for version control (like
> jQuery, MooTools, YUI or Prototype)... or if we can trust our remote
> helper for SCM in question (hmmm... I thought that jQuery uses
> Subversion, but it moved to Git).
>
> This way you don't need to have it if you don't need it... but on
> the other hand if you need it you have to download (clone) much
> larger development version. Sidenote: I wonder how well shallow
> clone and narrow checkout works with submodules.
>
> And of course we would have to somehow integrate build systems,
> i.e. have git call build system of JavaScript library when building
> and installing gitweb.
>
>
> We can check how other projects solve this issue:
>
> * MediaWiki (jQuery)::
>
> The jQuery file is in /resources/jquery/jquery.js, loaded
> (and minified) via ResourceLoader since version 1.17
>
> * WordPress (jQuery)::
>
> jQuery (development version) is in wp-includes/js/jquery/*
> in wordpress RPM
>
> * Movable Type (jQuery)::
>
> <script type="text/javascript" src="http://www.google.com/jsapi"></script>
> <script type="text/javascript">google.load("jquery", "1.3.2");</script>
>
> * Ruby on Rails (Prototype)
>
> jQuery (single file) is in gems/rails-*/html/javascripts/prototype.js
> in rails RPM
>
> There is of course question if theirs approach is good for gitweb...
>
>
> So what are your ideas and comments on the issue of JavaScript code
> and JavaScript libraries / frameworks in gitweb?
> --
> Jakub Narebski
> ShadeHawk on #git
> Poland
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Pozdrawiam,
Michał Łowicki
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: The future of gitweb - part 2: JavaScript
2011-04-14 19:30 ` Michał Łowicki
@ 2011-04-15 1:56 ` david
0 siblings, 0 replies; 30+ messages in thread
From: david @ 2011-04-15 1:56 UTC (permalink / raw)
To: Michał Łowicki
Cc: Jakub Narebski, git, John Hawley, Kevin Cernekee, Petr Baudis,
Petr Baudis
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2514 bytes --]
On Thu, 14 Apr 2011, Micha? ?owicki wrote:
> 2011/4/14 Jakub Narebski <jnareb@gmail.com>:
>>
>> Second issue is how to use it / how to include it:
>>
>> * Use some external Content Delivery Network (CDN), like
>> Google Libraries API
>> http://code.google.com/apis/libraries/devguide.html
>> e.g.:
>>
>> <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.5.2/jquery.min.js"></script>
>> <script src="http://code.jquery.com/jquery-1.5.2.min.js"></script>
>>
>> or
>>
>> <script src="https://ajax.googleapis.com/ajax/libs/mootools/1.3.1/mootools-yui-compressed.js"></script>
>>
>> This is nice solution... if we don't need plugin / extension
>> which usually are not available in CDN version of library.
>>
>> Also this makes gitweb dependent on third-party service, and require
>> network connectivity to Internet to have access to JavaScript-based
>> features.
>>
>> * Mark appropriate JavaScript library as dependency in gitweb/INSTALL
>> to be downloaded in appropriate place but do not provide sources.
>> Perhaps add target in gitweb/Makefile that automatically downloads
>> it.
>>
>> This would make installing gitweb correctly more complicated.
>> JavaScript-based features would not work if somebody instals gitweb
>> incorrectly.
>>
>> I think we can set up gitweb build so that one can configure at
>> build stage whether to use CDN or download library, or use
>> pre-downloaded (and perhaps instaled somewhere) version of framework
>> (combining JavaScript on build in all but first case).
>
> I'm not sure about pre-downloaded version of libs. Most of the time
> it's not a big deal but sometimes it may introduce hard to detect
> issues when someone use different version of the lib -
> http://ejohn.org/blog/learning-from-twitter/ .But the idea with
> options - CDN or download is very good. CDNs can improve the page
> download speed by increasing simultaneous connections if files are
> downloaded from many hostnames but for companies where instances of
> gitweb are on the Intrantet the 2nd option could be better I think (at
> least in my case). Additionaly CDNs can save some money when you pay
> for data traffic :)
another advantage of using the library from a CDN is that the user may
already have it cached in their browser and not have to download it at
all.
as long as there is a build-time option to make a version that does not
depend on being able to get to the Internet I think it's a good idea to
make the default use the Internet.
David Lang
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: The future of gitweb - part 2: JavaScript
2011-04-14 9:54 ` The future of gitweb - part 2: JavaScript Jakub Narebski
2011-04-14 19:30 ` Michał Łowicki
@ 2011-04-16 17:12 ` Peter Vereshagin
2011-04-16 19:32 ` Jakub Narebski
2011-04-16 17:44 ` The future of gitweb - part 2: JavaScript Pau Garcia i Quiles
` (2 subsequent siblings)
4 siblings, 1 reply; 30+ messages in thread
From: Peter Vereshagin @ 2011-04-16 17:12 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
Any time of year you can find me here Jakub.
2011/04/14 11:54:53 +0200 Jakub Narebski <jnareb@gmail.com> => To git@vger.kernel.org :
JN> So what are your ideas and comments on the issue of JavaScript code
JN> and JavaScript libraries / frameworks in gitweb?
I'd like to note here that js use intensification may be need to be kept
separated from extending of the http functions of the regular git use which I
believe is currnt;y implemented by mean of gitweb.
E. g., I think one day we shall be able to git-push, etc. to http(s) git
repository via http(s) the same way we can already git-fetch today. This is
another, less explicit way the gitweb is and will be being used, right? Having
that in mind I suppose some parts of gitweb development, e. g. code and/or docs
may need to be separated like it is done now for cli interface, the porcelain
versus plumbing, as both cli and the web can be considered to be the interfaces
One day it will be obvious for the non-interactive web clients like git to have
the js capabilities embedded. This will mean we perhaps will have technology
other than js for such a separation. But I believe gitweb will have js for ui
somewhat earlier.
73! Peter pgp: A0E26627 (4A42 6841 2871 5EA7 52AB 12F8 0CE1 4AAC A0E2 6627)
--
http://vereshagin.org
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: The future of gitweb - part 2: JavaScript
2011-04-16 17:12 ` Peter Vereshagin
@ 2011-04-16 19:32 ` Jakub Narebski
2011-04-16 20:48 ` Peter Vereshagin
0 siblings, 1 reply; 30+ messages in thread
From: Jakub Narebski @ 2011-04-16 19:32 UTC (permalink / raw)
To: Peter Vereshagin; +Cc: git
On Sat, 16 Apr 2011, Peter Vereshagin wrote:
> Any time of year you can find me here Jakub.
> 2011/04/14 11:54:53 +0200 Jakub Narebski <jnareb@gmail.com> => To git@vger.kernel.org :
> JN>
> JN> So what are your ideas and comments on the issue of JavaScript code
> JN> and JavaScript libraries / frameworks in gitweb?
>
> I'd like to note here that js use intensification may be need to be kept
> separated from extending of the http functions of the regular git use which I
> believe is currently implemented by mean of gitweb.
No, fetching and pushing using HTTP transport, be it "smart" or "dumb"
is _not_ the domain of gitweb.
Gitweb is web interface for _viewing and browsing_ repositories using
a web browser (e.g.: http://git.kernel.org, http://repo.or.cz). It
requires web server that can run CGI scripts, or FastCGI, or mod_perl
with ModPerl::Registry.
To fetch or push via "dumb" HTTP transport all you need is web server
(for push you need WebDAV configured), and a file generated by
'git update-server-info'. You don't need git on server... but this
transport is inefficient.
To fetch or push via "smart" HTTP transport you need git installed on
server (git-upload-pack and git-receive-pack), and web server that can
run CGI scripts and e.g. git-http-backend installed.
Neither of those require JavaScript... and neither of those is accessed
by web browser. You use git to fetch/push, not a web browser.
[cut]
--
Jakub Narebski
Poland
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: The future of gitweb - part 2: JavaScript
2011-04-16 19:32 ` Jakub Narebski
@ 2011-04-16 20:48 ` Peter Vereshagin
2011-04-16 21:17 ` Jakub Narebski
0 siblings, 1 reply; 30+ messages in thread
From: Peter Vereshagin @ 2011-04-16 20:48 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
God love is hard to find. You got lucky Jakub!
2011/04/16 21:32:56 +0200 Jakub Narebski <jnareb@gmail.com> => To Peter Vereshagin :
JN> No, fetching and pushing using HTTP transport, be it "smart" or "dumb"
JN> Gitweb is web interface for _viewing and browsing_ repositories using
Good for purposes I described earlier.
Bad for users to have different URLs as "URL is UI element" (c)
JN> with ModPerl::Registry.
but not PerlRun?
73! Peter pgp: A0E26627 (4A42 6841 2871 5EA7 52AB 12F8 0CE1 4AAC A0E2 6627)
--
http://vereshagin.org
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: The future of gitweb - part 2: JavaScript
2011-04-16 20:48 ` Peter Vereshagin
@ 2011-04-16 21:17 ` Jakub Narebski
2011-04-16 21:53 ` Peter Vereshagin
0 siblings, 1 reply; 30+ messages in thread
From: Jakub Narebski @ 2011-04-16 21:17 UTC (permalink / raw)
To: Peter Vereshagin; +Cc: git
On Sat, 16 Apr 2011, Peter Vereshagin wrote:
> God love is hard to find. You got lucky Jakub!
> 2011/04/16 21:32:56 +0200 Jakub Narebski <jnareb@gmail.com> => To Peter Vereshagin :
>
> JN> No, fetching and pushing using HTTP transport, be it "smart" or "dumb"
> JN> Gitweb is web interface for _viewing and browsing_ repositories using
>
> Good for purposes I described earlier.
> Bad for users to have different URLs as "URL is UI element" (c)
You can configure web server in such way that you can use the same
URL for fetching with git as for browsing repository with web browser
via gitweb, as described in git-http-backend manpage in one of
examples and also at the end of gitweb/README.
Nevertheless web browsing and fetching is done by two different
programs.
> JN> with ModPerl::Registry.
>
> but not PerlRun?
If it runs ModPerl::Registry (persistently), then it runs
ModPerl::PerlRun... but the reverse not always is true.
--
Jakub Narebski
Poland
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: The future of gitweb - part 2: JavaScript
2011-04-16 21:17 ` Jakub Narebski
@ 2011-04-16 21:53 ` Peter Vereshagin
2011-04-16 22:19 ` Jakub Narebski
0 siblings, 1 reply; 30+ messages in thread
From: Peter Vereshagin @ 2011-04-16 21:53 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Peter Vereshagin, git
You're face to face with man who sold the world, Jakub!
2011/04/16 23:17:55 +0200 Jakub Narebski <jnareb@gmail.com> => To Peter Vereshagin :
JN> > JN> No, fetching and pushing using HTTP transport, be it "smart" or "dumb"
JN> > JN> Gitweb is web interface for _viewing and browsing_ repositories using
JN> You can configure web server in such way that you can use the same
JN> URL for fetching with git as for browsing repository with web browser
There are more disadvantages of such an approach:
- for CGI, the process is being executed on every request. On some systems, e.
g., Windows, launching a process is very expensive, sometimes more than
compiling of perl source itself.
- for development, some different parts of the code for the same purpose do
exist, e. g., client and storage i/o. The more it is being developed, the
more features it satisfies, the more such a code. For example, I suppose
git-http-backend will have 'get a particular commitdiff quickly without
fetching all the repo' feature one day to be used in web clients' scripts, e.
g. will serve the same way for git cli as a file system. This will make it have
the same feature like 'commitdiff' feature of a gitweb but implemented
differently.
- the routing of the request, the deciding what to do with the particular
HTTP request, becomes more obfuscated. First, web server decides what CGI
should approve it. Plus two more decision makers are those 2 CGI, all different.
It's just why I never supposed git to have 2 different native web interfaces,
especially in sight of plumbing vs porcelain contrast in cli, sorry for
confusion.
73! Peter pgp: A0E26627 (4A42 6841 2871 5EA7 52AB 12F8 0CE1 4AAC A0E2 6627)
--
http://vereshagin.org
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: The future of gitweb - part 2: JavaScript
2011-04-16 21:53 ` Peter Vereshagin
@ 2011-04-16 22:19 ` Jakub Narebski
2011-04-16 22:33 ` Jakub Narebski
2011-04-16 23:00 ` Peter Vereshagin
0 siblings, 2 replies; 30+ messages in thread
From: Jakub Narebski @ 2011-04-16 22:19 UTC (permalink / raw)
To: Peter Vereshagin; +Cc: git
On Sat, 16 Apr 2011, Peter Vereshagin wrote:
> You're face to face with man who sold the world, Jakub!
> 2011/04/16 23:17:55 +0200 Jakub Narebski <jnareb@gmail.com> => To Peter Vereshagin :
> JN> > JN> No, fetching and pushing using HTTP transport, be it "smart" or "dumb"
> JN> > JN> Gitweb is web interface for _viewing and browsing_ repositories using
> JN>
> JN> You can configure web server in such way that you can use the same
> JN> URL for fetching with git as for browsing repository with web browser
>
> There are more disadvantages of such an approach:
> - for CGI, the process is being executed on every request. On some systems, e.
> g., Windows, launching a process is very expensive, sometimes more than
> compiling of perl source itself.
You can run gitweb as a persistent web app, using it either as FastCGI
script, or via mod_perl + ModPerl::Registry.
git-http-backend is written in C, not Perl.
> - for development, some different parts of the code for the same purpose do
> exist, e. g., client and storage i/o. The more it is being developed, the
> more features it satisfies, the more such a code.
Gitweb is written in Perl. This language is good for prototyping, for
fast development, and for easy writing of a web app. Gitweb works on
porcelain level - it is an user interface (a web one).
C is good for performance. git-http-backend is only an example
implementation. The "smart" HTTP protocol works on porcelain level.
> For example, I suppose git-http-backend will have 'get a particular
> commitdiff quickly without fetching all the repo' feature one day
> to be used in web clients' scripts, e.g. will serve the same way
> for git cli as a file system. This will make it have the same
> feature like 'commitdiff' feature of a gitweb but implemented
> differently.
Unix philosophy which Git tries to follow is "do one thing and do it
well".
I don't believe git-http-backend would ever talk to web browsers, and
it is quite unlikely for git to acquire non-distributed client-server
mode.
And if it does acquire such feature, then gitweb will be simply modified
to use it...
> - the routing of the request, the deciding what to do with the particular
> HTTP request, becomes more obfuscated. First, web server decides what CGI
> should approve it. Plus two more decision makers are those 2 CGI, all different.
>
> It's just why I never supposed git to have 2 different native web interfaces,
> especially in sight of plumbing vs porcelain contrast in cli, sorry for
> confusion.
Those are not two _web interfaces_. Gitweb is one of web interfaces
to git repositories; more at
https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools#Web_Interfaces
Fetching and pushing via HTTP is not web interface, is HTTP _transport_.
For one you use web browser, for other you use git itself.
But this discussion got very off-topic...
--
Jakub Narebski
Poland
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: The future of gitweb - part 2: JavaScript
2011-04-16 22:19 ` Jakub Narebski
@ 2011-04-16 22:33 ` Jakub Narebski
2011-04-16 23:00 ` Peter Vereshagin
1 sibling, 0 replies; 30+ messages in thread
From: Jakub Narebski @ 2011-04-16 22:33 UTC (permalink / raw)
To: Peter Vereshagin; +Cc: git
Jakub Narebski wrote:
> Gitweb is written in Perl. This language is good for prototyping, for
> fast development, and for easy writing of a web app. Gitweb works on
> porcelain level - it is an user interface (a web one).
>
> C is good for performance. git-http-backend is only an example
> implementation. The "smart" HTTP protocol works on porcelain level.
^^^^^^^^^
I meant plumbing here.
--
Jakub Narebski
Poland
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: The future of gitweb - part 2: JavaScript
2011-04-16 22:19 ` Jakub Narebski
2011-04-16 22:33 ` Jakub Narebski
@ 2011-04-16 23:00 ` Peter Vereshagin
2011-04-17 10:11 ` Jakub Narebski
1 sibling, 1 reply; 30+ messages in thread
From: Peter Vereshagin @ 2011-04-16 23:00 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
You're face to face with man who sold the world, Jakub!
2011/04/17 00:19:07 +0200 Jakub Narebski <jnareb@gmail.com> => To Peter Vereshagin :
JN> > There are more disadvantages of such an approach:
JN> > - for CGI, the process is being executed on every request. On some systems, e.
JN> > g., Windows, launching a process is very expensive, sometimes more than
JN> git-http-backend is written in C, not Perl.
Yes, it's about it.
JN> > - for development, some different parts of the code for the same purpose do
JN> > exist, e. g., client and storage i/o. The more it is being developed, the
JN> > more features it satisfies, the more such a code.
JN>
JN> Gitweb is written in Perl. This language is good for prototyping, for
JN> fast development, and for easy writing of a web app. Gitweb works on
JN> porcelain level - it is an user interface (a web one).
JN>
JN> C is good for performance. git-http-backend is only an example
JN> implementation. The "smart" HTTP protocol works on porcelain level.
It doesn't mean that different parts of code do exist in them for the same purpose.
It doesn't mean that such a code can not be reused by both.
C code can be used by Perl.
JN> > For example, I suppose git-http-backend will have 'get a particular
JN> > commitdiff quickly without fetching all the repo' feature one day
JN> > to be used in web clients' scripts, e.g. will serve the same way
JN> > for git cli as a file system. This will make it have the same
JN> > feature like 'commitdiff' feature of a gitweb but implemented
JN> > differently.
JN>
JN> Unix philosophy which Git tries to follow is "do one thing and do it
JN> well".
This is why the code must not be reused?
Does it mean "there is more than one way to do it and we will use all of them for the same purpose in the same project"?
JN> I don't believe git-http-backend would ever talk to web browsers, and
JN> it is quite unlikely for git to acquire non-distributed client-server
JN> mode.
This is why I must not have a possibility to check out N latest commitdiffs easily from my script to recognize current state of the particular repo's art without fetching all over the repo? Suppose repo doesn't have a porcelain web interface, but even if it does, it's not for it.
JN> And if it does acquire such feature, then gitweb will be simply modified
JN> to use it...
or git-http-backend? or both?
isn't it just better for them to reuse the same code?
JN> > - the routing of the request, the deciding what to do with the particular
JN> > HTTP request, becomes more obfuscated. First, web server decides what CGI
JN> > should approve it. Plus two more decision makers are those 2 CGI, all different.
JN> >
JN> > It's just why I never supposed git to have 2 different native web interfaces,
JN> > especially in sight of plumbing vs porcelain contrast in cli, sorry for
JN> > confusion.
JN>
JN> Those are not two _web interfaces_. Gitweb is one of web interfaces
JN> to git repositories; more at
JN> https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools#Web_Interfaces
JN>
JN> Fetching and pushing via HTTP is not web interface, is HTTP _transport_.
but HTTP is an application protocol, not a transport protocol. And the what the application supplies by the protocol is the interface.
Do you mean the Git's plumbing is a protocol and not an interface to be used by application? And porcelain is an interface, correspondently.
JN> For one you use web browser, for other you use git itself.
on the client side those are different projects.
on the server side those are the same.
Different technologies, right. But not incompatible.
JN> But this discussion got very off-topic...
Not about Javascript, right.
73! Peter pgp: A0E26627 (4A42 6841 2871 5EA7 52AB 12F8 0CE1 4AAC A0E2 6627)
--
http://vereshagin.org
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: The future of gitweb - part 2: JavaScript
2011-04-16 23:00 ` Peter Vereshagin
@ 2011-04-17 10:11 ` Jakub Narebski
2011-04-20 18:24 ` Gitweb != HTTP back-end {Was: Re: The future of gitweb - part 2: JavaScript} Drew Northup
0 siblings, 1 reply; 30+ messages in thread
From: Jakub Narebski @ 2011-04-17 10:11 UTC (permalink / raw)
To: Peter Vereshagin; +Cc: git
On Sun, 17 Apr 2011, Peter Vereshagin wrote:
> You're face to face with man who sold the world, Jakub!
> 2011/04/17 00:19:07 +0200 Jakub Narebski <jnareb@gmail.com> => To Peter Vereshagin :
> JN> > There are more disadvantages of such an approach:
> JN> > - for CGI, the process is being executed on every request. On some systems, e.
> JN> > g., Windows, launching a process is very expensive, sometimes more than
> JN> git-http-backend is written in C, not Perl.
>
> Yes, it's about it.
Perl is much better for writing a web app such as gitweb (meant for
web browsers) than bare C.
> JN> > - for development, some different parts of the code for the same purpose do
> JN> > exist, e. g., client and storage i/o. The more it is being developed, the
> JN> > more features it satisfies, the more such a code.
> JN>
> JN> Gitweb is written in Perl. This language is good for prototyping, for
> JN> fast development, and for easy writing of a web app. Gitweb works on
> JN> porcelain level - it is an user interface (a web one).
> JN>
> JN> C is good for performance. git-http-backend is only an example
> JN> implementation. The "smart" HTTP protocol works on porcelain level.
>
> It doesn't mean that different parts of code do exist in them
> for the same purpose. It doesn't mean that such a code can not
> be reused by both. C code can be used by Perl.
C code can be used by Perl... but if you mean calling C code from Perl
then first, there is no git library; libgit2 is work in progress yet.
Second, there are no Perl bindings for libgit2. Third, doing Perl
bindings to C in _portable_ way is major pain; XS is hard (this might
change if/when Perl port of ctypes would be finished).
If you mean calling git commands from gitweb and parsing their output...
that is what gitweb does.
But gitweb and git-http-backend doesn't have much common in
functionality.
> JN> > For example, I suppose git-http-backend will have 'get a particular
> JN> > commitdiff quickly without fetching all the repo' feature one day
> JN> > to be used in web clients' scripts, e.g. will serve the same way
> JN> > for git cli as a file system. This will make it have the same
> JN> > feature like 'commitdiff' feature of a gitweb but implemented
> JN> > differently.
> JN>
> JN> Unix philosophy which Git tries to follow is "do one thing and do it
> JN> well".
>
> This is why the code must not be reused?
What is about code reuse? Gitweb calls git commands, and generates
output in HTML for web browser. git-http-backend is responsible for
communicating with git-upload-pack / git-receive-pack on behalf of git
client.
> Does it mean "there is more than one way to do it and we will use
> all of them for the same purpose in the same project"?
No.
This means that it is gitweb job to tak to web browser, git-http-backend
to talk to "git fetch" or "git push", and web server to route to
correct script (backend).
> JN> I don't believe git-http-backend would ever talk to web browsers, and
> JN> it is quite unlikely for git to acquire non-distributed client-server
> JN> mode.
[...]
> JN> And if it does acquire such feature, then gitweb will be simply modified
> JN> to use it...
>
> or git-http-backend? or both?
Gitweb, because it is porcelain. git-http-backend is plumbing. It is
porcelain (high level, meant for end user) that uses plumbing (low level,
meant for scripts and other commands).
> isn't it just better for them to reuse the same code?
There is nothing to reuse.
> JN> > - the routing of the request, the deciding what to do with the particular
> JN> > HTTP request, becomes more obfuscated. First, web server decides what CGI
> JN> > should approve it. Plus two more decision makers are those 2 CGI, all different.
> JN> >
> JN> > It's just why I never supposed git to have 2 different native web interfaces,
> JN> > especially in sight of plumbing vs porcelain contrast in cli, sorry for
> JN> > confusion.
> JN>
> JN> Those are not two _web interfaces_. Gitweb is one of web interfaces
> JN> to git repositories; more at
> JN> https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools#Web_Interfaces
> JN>
> JN> Fetching and pushing via HTTP is not web interface, is HTTP _transport_.
>
> But HTTP is an application protocol, not a transport protocol.
Fetching via "smart" HTTP protocol is actually git-over-http, with
some extra work due to the fact that HTTP is stateless.
> JN> For one [gitweb] you use web browser, for other [git-http-backend]
> JN> you use git itself.
>
> on the client side those are different projects.
> on the server side those are the same.
No, they are not the same. Besides minuscule part of being a CGI script
they have nothing in common. Gitweb produces HTML output for consumption
of web browser in response to given URL. git-http-backend proxies fetch
and push request to git-upload-pack / git-receive-pack.
>
> Different technologies, right. But not incompatible.
There is nothing to be compatible with.
> JN> But this discussion got very off-topic...
>
> Not about Javascript, right.
Well, except the fact that "git fetch" / "git push" is not a web browser,
and that it would never use JavaScript... so git-http-backend wouldn't
either.
But it is not about JavaScript use by gitweb.
--
Jakub Narebski
Poland
^ permalink raw reply [flat|nested] 30+ messages in thread* Gitweb != HTTP back-end {Was: Re: The future of gitweb - part 2: JavaScript}
2011-04-17 10:11 ` Jakub Narebski
@ 2011-04-20 18:24 ` Drew Northup
2011-04-20 18:47 ` Jakub Narebski
0 siblings, 1 reply; 30+ messages in thread
From: Drew Northup @ 2011-04-20 18:24 UTC (permalink / raw)
To: Peter Vereshagin; +Cc: git, Jakub Narebski
On Sun, 2011-04-17 at 12:11 +0200, Jakub Narebski wrote:
> On Sun, 17 Apr 2011, Peter Vereshagin wrote:
> > 2011/04/17 00:19:07 +0200 Jakub Narebski <jnareb@gmail.com> => To Peter Vereshagin :
> > JN> > - the routing of the request, the deciding what to do with the particular
> > JN> > HTTP request, becomes more obfuscated. First, web server decides what CGI
> > JN> > should approve it. Plus two more decision makers are those 2 CGI, all different.
> > JN> >
> > JN> > It's just why I never supposed git to have 2 different native web interfaces,
> > JN> > especially in sight of plumbing vs porcelain contrast in cli, sorry for
> > JN> > confusion.
> > JN>
> > JN> Those are not two _web interfaces_. Gitweb is one of web interfaces
> > JN> to git repositories; more at
> > JN> https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools#Web_Interfaces
> > JN>
> > JN> Fetching and pushing via HTTP is not web interface, is HTTP _transport_.
> >
> > But HTTP is an application protocol, not a transport protocol.
Forgive me, but this is seriously off-base.
HTTP := Hyper-Text Transport Protocol.
It is a generic, stateless, way of moving text (Base-64 encoded for
binary data) over the wire. Sure, the ISO/OSI model may classify it as
an "application," but that term does not mean the same thing in all
contexts. As far as Git is concerned it is a transport; as far as the
ISO/OSI model of networking is concerned it is an application. We aren't
talking here about the latter.
Or perhaps you are confusing an HTTP-speaking "application" (Gitweb) and
the Git-over-HTTP back-end. They do not have the same purpose. As far as
I'm aware only the "cgit" web interface supports the Git-over-HTTP
"client" directly (and only the dumb one apparently). This may be what
has you confused.
>
> Fetching via "smart" HTTP protocol is actually git-over-http, with
> some extra work due to the fact that HTTP is stateless.
...and Base-64 encoded, and chunked, and so on...
None of this has anything to do with Javascript.
--
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: Gitweb != HTTP back-end {Was: Re: The future of gitweb - part 2: JavaScript}
2011-04-20 18:24 ` Gitweb != HTTP back-end {Was: Re: The future of gitweb - part 2: JavaScript} Drew Northup
@ 2011-04-20 18:47 ` Jakub Narebski
0 siblings, 0 replies; 30+ messages in thread
From: Jakub Narebski @ 2011-04-20 18:47 UTC (permalink / raw)
To: Drew Northup; +Cc: Peter Vereshagin, git
On Wed, 20 Apr 2011, Drew Northup wrote:
> On Sun, 2011-04-17 at 12:11 +0200, Jakub Narebski wrote:
>> On Sun, 17 Apr 2011, Peter Vereshagin wrote:
>>> 2011/04/17 00:19:07 +0200 Jakub Narebski <jnareb@gmail.com> => To Peter Vereshagin :
>>> JN> Fetching and pushing via HTTP is not web interface, is HTTP _transport_.
>>>
>>> But HTTP is an application protocol, not a transport protocol.
>
> Forgive me, but this is seriously off-base.
> HTTP := Hyper-Text Transport Protocol.
>
> It is a generic, stateless, way of moving text (Base-64 encoded for
> binary data) over the wire. Sure, the ISO/OSI model may classify it as
> an "application," but that term does not mean the same thing in all
> contexts. As far as Git is concerned it is a transport; as far as the
> ISO/OSI model of networking is concerned it is an application. We aren't
> talking here about the latter.
Note that it is the same relation as Git has with SSH: for Git it is
(statefull and binary-safe, and authenthicated and encrypted) way
of transporting data.
>>
>> Fetching via "smart" HTTP protocol is actually git-over-http, with
>> some extra work due to the fact that HTTP is stateless.
>
> ...and Base-64 encoded, and chunked, and so on...
But with git-http-backend being a CGI script, this is what web server
does; git doesn't need to worry about it, but it has to worry about
HTTP being stateless.
--
Jakub Narebski
Poland
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: The future of gitweb - part 2: JavaScript
2011-04-14 9:54 ` The future of gitweb - part 2: JavaScript Jakub Narebski
2011-04-14 19:30 ` Michał Łowicki
2011-04-16 17:12 ` Peter Vereshagin
@ 2011-04-16 17:44 ` Pau Garcia i Quiles
2011-04-17 14:59 ` Jakub Narebski
2011-04-17 20:14 ` Petr Baudis
2011-04-20 18:39 ` Drew Northup
4 siblings, 1 reply; 30+ messages in thread
From: Pau Garcia i Quiles @ 2011-04-16 17:44 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, John Hawley, Kevin Cernekee, Petr Baudis, Petr Baudis
Hi,
My suggestion is going to be tremendously unpopular, but still: if I
were to develop my own gitweb, I'd use Wt ( http://webtoolkit.eu ) +
libgit2. In fact, there is a very basic gitweb-like example bundled
with Wt sources, it's available online at
http://www.webtoolkit.eu/wt/examples/git
All those detect if this feature is available or not, fallback to
plain HTML (no Javascript, no AJAX), use HTML5, or SVG, or... where
available are already solved (and are totally automatical) in Wt. It's
C++ with Boost and Qt-like API, not plain C, Perl or bash scripting,
though.
On Thu, Apr 14, 2011 at 11:54 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>
> This is second installment, talking about JavaScript (client-side)
> part of gitweb code.
> [...]
> Those issues are already solved in __JavaScript libraries__ and
> frameworks, probably better way than in our attempt. Using JavaScript
> framework would also give as higher level constructs, and could
> replace what we have and could have in gitweb/static/js/lib:
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: The future of gitweb - part 2: JavaScript
2011-04-16 17:44 ` The future of gitweb - part 2: JavaScript Pau Garcia i Quiles
@ 2011-04-17 14:59 ` Jakub Narebski
2011-04-17 15:14 ` Pau Garcia i Quiles
0 siblings, 1 reply; 30+ messages in thread
From: Jakub Narebski @ 2011-04-17 14:59 UTC (permalink / raw)
To: Pau Garcia i Quiles
Cc: git, John Hawley, Kevin Cernekee, Petr Baudis, Petr Baudis
On Sat, 16 Apr 2011, Pau Garcia i Quiles wrote:
> On Thu, Apr 14, 2011 at 11:54 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> >
> > This is second installment, talking about JavaScript (client-side)
> > part of gitweb code.
> > [...]
> > Those issues are already solved in __JavaScript libraries__ and
> > frameworks, probably better way than in our attempt. Using JavaScript
> > framework would also give as higher level constructs, and could
> > replace what we have and could have in gitweb/static/js/lib:
> My suggestion is going to be tremendously unpopular, but still: if I
> were to develop my own gitweb, I'd use Wt ( http://webtoolkit.eu ) +
> libgit2. In fact, there is a very basic gitweb-like example bundled
> with Wt sources, it's available online at
> http://www.webtoolkit.eu/wt/examples/git
Well, nothing prevents you or anybody else from writing (yet another)
web interface in C++ + Wt + libgit2. Gitweb is not the only git web
interface:
https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools#Web_Interfaces
There is Gitalist in Perl which uses Catalyst MVC framework, cgit in
C linking directly to git (libgit.a), git-php and ViewGit in PHP, etc.
> All those detect if this feature is available or not, fallback to
> plain HTML (no Javascript, no AJAX), use HTML5, or SVG, or... where
> available are already solved (and are totally automatical) in Wt. It's
> C++ with Boost and Qt-like API, not plain C, Perl or bash scripting,
> though.
Gitweb has the advantage that if you can install git, and you have web
server with CGI support, you can install and run gitweb. First part
of series was about relaxing this "no non-core dependencies required"
requirement. Requiring to install C++ / libstdc++, Boost and Wt...
Note that git chosen to write strbuf and parseopt from scratch,
instead of using some existing library (bstrings, Boost, popt,...).
So, as yet another web interface, fine. As replacement for gitweb:
I don't think so.
BTW. do I understand correctly that Wt generates JavaScript code, in
similar vein to GWT for Java, or Pyjamas for Python?
--
Jakub Narebski
Poland
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: The future of gitweb - part 2: JavaScript
2011-04-17 14:59 ` Jakub Narebski
@ 2011-04-17 15:14 ` Pau Garcia i Quiles
2011-04-18 18:13 ` Jakub Narebski
0 siblings, 1 reply; 30+ messages in thread
From: Pau Garcia i Quiles @ 2011-04-17 15:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, John Hawley, Kevin Cernekee, Petr Baudis, Petr Baudis
On Sun, Apr 17, 2011 at 4:59 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> My suggestion is going to be tremendously unpopular, but still: if I
>> were to develop my own gitweb, I'd use Wt ( http://webtoolkit.eu ) +
>> libgit2. In fact, there is a very basic gitweb-like example bundled
>> with Wt sources, it's available online at
>> http://www.webtoolkit.eu/wt/examples/git
>
> Well, nothing prevents you or anybody else from writing (yet another)
> web interface in C++ + Wt + libgit2.
I do not have the slightest intention of doing that, at least not in
my spare time. The existing interfaces (gitweb, cgit, etc) are good
enough for me. I made the suggestion of going with Wt just in case a
rewrite of gitweb was in mind.
> Gitweb has the advantage that if you can install git, and you have web
> server with CGI support, you can install and run gitweb. First part
> of series was about relaxing this "no non-core dependencies required"
> requirement. Requiring to install C++ / libstdc++, Boost and Wt...
Sure, that's why I mentioned the dependencies. No dependencies is a
major feature in itself in some environments.
> BTW. do I understand correctly that Wt generates JavaScript code, in
> similar vein to GWT for Java, or Pyjamas for Python?
Wt generates Javascript only if the visitor has Javascript enabled. If
Javascript is not available, it will generate plain HTML pages, with
"update" buttons, etc and it will do that automatically: there is no
need for you to write code "if Javascript is available { ... } else {
... }".
The advantage of Wt is you can compile a hypothetical gitwebwt as a
static executable and the result will be a single executable file that
depends only on libc (or libc + git, if you call git instead of
linking to libgit.a or libgit2). Also, performance and memory
requirements are very good, which is important for not-that-powerful
devices such as routers, etc.
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: The future of gitweb - part 2: JavaScript
2011-04-17 15:14 ` Pau Garcia i Quiles
@ 2011-04-18 18:13 ` Jakub Narebski
0 siblings, 0 replies; 30+ messages in thread
From: Jakub Narebski @ 2011-04-18 18:13 UTC (permalink / raw)
To: Pau Garcia i Quiles
Cc: git, John Hawley, Kevin Cernekee, Petr Baudis, Petr Baudis
On Sun, 17 Apr 2011, Pau Garcia i Quiles wrote:
> On Sun, Apr 17, 2011 at 4:59 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>
>>> My suggestion is going to be tremendously unpopular, but still: if I
>>> were to develop my own gitweb, I'd use Wt ( http://webtoolkit.eu ) +
>>> libgit2. In fact, there is a very basic gitweb-like example bundled
>>> with Wt sources, it's available online at
>>> http://www.webtoolkit.eu/wt/examples/git
>>
>> Well, nothing prevents you or anybody else from writing (yet another)
>> web interface in C++ + Wt + libgit2.
>
> I do not have the slightest intention of doing that, at least not in
> my spare time. The existing interfaces (gitweb, cgit, etc) are good
> enough for me.
I can certainly understand that... ;-)
> I made the suggestion of going with Wt just in case a
> rewrite of gitweb was in mind.
No, major rewrite of gitweb is certainly not on agenda. Besides IMVVHO
rewriting a long-lived existing application / project from scratch is
usually a bad idea; you would almost certainly repeat old mistakes.
If code is bad enough that it hinders maintenance and development, it is
better to do refactoring, trying to keep project working as it was.
The question was more about future features.
[...]
>> BTW. do I understand correctly that Wt generates JavaScript code, in
>> similar vein to GWT for Java, or Pyjamas for Python?
>
> Wt generates Javascript only if the visitor has Javascript enabled. If
> Javascript is not available, it will generate plain HTML pages, with
> "update" buttons, etc and it will do that automatically: there is no
> need for you to write code "if Javascript is available { ... } else {
> ... }".
Well, actually sometimes you need to know if JavaScript is available...
for example in the case of gitweb there is separate 'blame' view which
runs 'git blame --porcelain' which can take a while, and Ajax-y
'blame_incremental' which runs 'git cat-file -p' + 'git blame --incremental'
in background via XmlHttpRequest. Different server-side reactions;
and doing both would be really counterproductive wrt. performance.
On the other hand it would be nice to write almost the same algorithm
of parsing 'git blame --porcelain' and 'git blame --incremental' output,
and of generating or manipulating output to the same look ONCE, and not
one time in Perl, one time in JavaScript.
Unfortunately I haven't found anything on CPAN that would be Perl
equivalent of Java's GWT, C++'s Wt, or Python's Pyjamas... well except
not quite here CGI::Ajax. Besides even using CGI::Ajax goes against
current "no non-core dependencies" policy...
BTW. there is Continuity Perl web framework which I think is similar
to Wt in that it manages state of web app like Wt does.
> The advantage of Wt is you can compile a hypothetical gitwebwt as a
> static executable and the result will be a single executable file that
> depends only on libc (or libc + git, if you call git instead of
> linking to libgit.a or libgit2). Also, performance and memory
> requirements are very good, which is important for not-that-powerful
> devices such as routers, etc.
Nice.
--
Jakub Narebski
Poland
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: The future of gitweb - part 2: JavaScript
2011-04-14 9:54 ` The future of gitweb - part 2: JavaScript Jakub Narebski
` (2 preceding siblings ...)
2011-04-16 17:44 ` The future of gitweb - part 2: JavaScript Pau Garcia i Quiles
@ 2011-04-17 20:14 ` Petr Baudis
2011-04-18 13:34 ` Jakub Narebski
2011-04-20 18:39 ` Drew Northup
4 siblings, 1 reply; 30+ messages in thread
From: Petr Baudis @ 2011-04-17 20:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, John Hawley, Kevin Cernekee
Hi!
On Thu, Apr 14, 2011 at 11:54:53AM +0200, Jakub Narebski wrote:
> Unfortunately the decision to use JavaScript framework brings its own
> new problems.
>
> First issue is which JavaScript framework or library to use:
> * jQuery (lightweight, most popular, used e.g. by MediaWiki)
> * MooTools (lightweight, 2nd most popular, opbject-oriented)
> * YUI, The Yahoo! User Interface Library
> * other: Prototype, Dojo, ExtJS, SproutCore,...
Girocco uses MooTools, and I also used it in an old private branch
of gitweb. I have had pretty good experience with it. But since I wasn't
able to find anyone to maintain Girocco's gitweb (or even keep it in
sync with upstream) and the patch flow to core git has dried up, it's
probably not too relevant argument. :-)
> So what are your ideas and comments on the issue of JavaScript code
> and JavaScript libraries / frameworks in gitweb?
It seems most common sense to use CDN by default but allow providing
pre-downloaded file with the library at build time as an alternative.
--
Petr "Pasky" Baudis
UNIX is user friendly, it's just picky about who its friends are.
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: The future of gitweb - part 2: JavaScript
2011-04-17 20:14 ` Petr Baudis
@ 2011-04-18 13:34 ` Jakub Narebski
2011-04-18 13:50 ` Petr Baudis
0 siblings, 1 reply; 30+ messages in thread
From: Jakub Narebski @ 2011-04-18 13:34 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, John Hawley, Kevin Cernekee
On Sun, 17 Apr 2011, Petr Baudis wrote:
> On Thu, Apr 14, 2011 at 11:54:53AM +0200, Jakub Narebski wrote:
> > Unfortunately the decision to use JavaScript framework brings its own
> > new problems.
> >
> > First issue is which JavaScript framework or library to use:
> > * jQuery (lightweight, most popular, used e.g. by MediaWiki)
> > * MooTools (lightweight, 2nd most popular, opbject-oriented)
> > * YUI, The Yahoo! User Interface Library
> > * other: Prototype, Dojo, ExtJS, SproutCore,...
>
> Girocco uses MooTools, and I also used it in an old private branch
> of gitweb. I have had pretty good experience with it. But since I wasn't
> able to find anyone to maintain Girocco's gitweb (or even keep it in
> sync with upstream) and the patch flow to core git has dried up, it's
> probably not too relevant argument. :-)
Thanks. The information about MooTools is certain helpful.
Do you remember why did you choose MooTools from other existing JavaScript
frameworks, including more popular jQuery?
> > So what are your ideas and comments on the issue of JavaScript code
> > and JavaScript libraries / frameworks in gitweb?
>
> It seems most common sense to use CDN by default but allow providing
> pre-downloaded file with the library at build time as an alternative.
This seems to be a consensus. Now what's left is to worry about plugins,
extensions etc. which would be helpful for gitweb JavaScript use, but
are not in core provided by CDN.
--
Jakub Narebski
Poland
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: The future of gitweb - part 2: JavaScript
2011-04-18 13:34 ` Jakub Narebski
@ 2011-04-18 13:50 ` Petr Baudis
2011-04-18 14:15 ` Jakub Narebski
0 siblings, 1 reply; 30+ messages in thread
From: Petr Baudis @ 2011-04-18 13:50 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, John Hawley, Kevin Cernekee
Hi!
On Mon, Apr 18, 2011 at 03:34:30PM +0200, Jakub Narebski wrote:
> On Sun, 17 Apr 2011, Petr Baudis wrote:
> > Girocco uses MooTools, and I also used it in an old private branch
> > of gitweb. I have had pretty good experience with it. But since I wasn't
> > able to find anyone to maintain Girocco's gitweb (or even keep it in
> > sync with upstream) and the patch flow to core git has dried up, it's
> > probably not too relevant argument. :-)
>
> Thanks. The information about MooTools is certain helpful.
>
> Do you remember why did you choose MooTools from other existing JavaScript
> frameworks, including more popular jQuery?
Unfortunately, it was few years back so I don't remember clearly
anymore - it certainly was not a very educated guess, however, since I'm
not really a JavaScript hacker. Possibly I just stumbled on a nicer
guide for MooTools than jQuery at that time. By now, it's quite possible
that jQuery is a friendlier alternative.
--
Petr "Pasky" Baudis
UNIX is user friendly, it's just picky about who its friends are.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: The future of gitweb - part 2: JavaScript
2011-04-18 13:50 ` Petr Baudis
@ 2011-04-18 14:15 ` Jakub Narebski
0 siblings, 0 replies; 30+ messages in thread
From: Jakub Narebski @ 2011-04-18 14:15 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, John Hawley, Kevin Cernekee
On Mon, 18 Apr 2011, Petr Baudis wrote:
> On Mon, Apr 18, 2011 at 03:34:30PM +0200, Jakub Narebski wrote:
> > On Sun, 17 Apr 2011, Petr Baudis wrote:
> > > Girocco uses MooTools, and I also used it in an old private branch
> > > of gitweb. I have had pretty good experience with it. But since I wasn't
> > > able to find anyone to maintain Girocco's gitweb (or even keep it in
> > > sync with upstream) and the patch flow to core git has dried up, it's
> > > probably not too relevant argument. :-)
> >
> > Thanks. The information about MooTools is certain helpful.
> >
> > Do you remember why did you choose MooTools from other existing JavaScript
> > frameworks, including more popular jQuery?
>
> Unfortunately, it was few years back so I don't remember clearly
> anymore - it certainly was not a very educated guess, however, since I'm
> not really a JavaScript hacker. Possibly I just stumbled on a nicer
> guide for MooTools than jQuery at that time. By now, it's quite possible
> that jQuery is a friendlier alternative.
Well, I am also partial to MooTools. I haven't examined all JavaScript
frameworks, or did examination in much detail, but from jQuery, MooTools
and YUI I think MooTools looks best. jQuery looks a bit too little,
being mainly about DOM manipulation (though it has lots of plugins), YUI
being a bit too much (gitweb doesn't need and shouldn't need all this);
MooTools look about right (and has More and forge / plugins)... and is
second most popular after jQuery ;-)
But I'm willing to be persuaded.
What gitweb needs currently (meaning existing JavaScrip and patches
in flight):
* support for old browsers that might not have findElementsByClassName
of querySelectorAll
* formatting Date in RFC2822-like format
* event delegation (live events)
* support for onprogress for XHR, emulated if necessary
* attaching / detaching simple floating menu
References:
^^^^^^^^^^^
* http://jqueryvsmootools.com/ (by MooTools developer)
* http://stackoverflow.com/questions/394601/which-javascript-framework-jquery-vs-dojo-vs
--
Jakub Narebski
Poland
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: The future of gitweb - part 2: JavaScript
2011-04-14 9:54 ` The future of gitweb - part 2: JavaScript Jakub Narebski
` (3 preceding siblings ...)
2011-04-17 20:14 ` Petr Baudis
@ 2011-04-20 18:39 ` Drew Northup
4 siblings, 0 replies; 30+ messages in thread
From: Drew Northup @ 2011-04-20 18:39 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, John Hawley, Kevin Cernekee, Petr Baudis, Petr Baudis
On Thu, 2011-04-14 at 11:54 +0200, Jakub Narebski wrote:
> * incremental blame (Ajax-y, requires server side knowing above)
> * setting local timezone in which dates are shown
>
> Possible other JavaScript-based enhancements include:
> * sorting tables like in Wikipedia, avoiding trip to server
> * MediaWiki-like history view for selecting commits to compare
> (base does not exist yet, and could be used without JavaScript)
> First issue is which JavaScript framework or library to use:
> * jQuery (lightweight, most popular, used e.g. by MediaWiki)
> * MooTools (lightweight, 2nd most popular, opbject-oriented)
> * YUI, The Yahoo! User Interface Library
> * other: Prototype, Dojo, ExtJS, SproutCore,...
>
>
> Second issue is how to use it / how to include it:
>
> * Use some external Content Delivery Network (CDN), like
> Google Libraries API
> * Mark appropriate JavaScript library as dependency in gitweb/INSTALL
> to be downloaded in appropriate place but do not provide sources.
> Perhaps add target in gitweb/Makefile that automatically downloads
> it.
> * Provide copy in git sources (in git.git repository), minified or
> development version or both. This would bloat git repository a bit,
> and we would probably want/have to update library at its releases.
> * Instead of including source code or build (minified) version in git
> repository, we could include JavaScript library as a _submodule_.
> * WordPress (jQuery)::
>
> jQuery (development version) is in wp-includes/js/jquery/*
> in wordpress RPM
> So what are your ideas and comments on the issue of JavaScript code
> and JavaScript libraries / frameworks in gitweb?
I would like to note that we are going to have to stick with a specific
version of whatever we end up using during a release/bugfix family. A
failure to do this has led to numerous headaches over in WordPress land.
Some theme designers were going out on a limb and overriding the version
of jQuery that WordPress itself includes (sometimes with a newer one,
sometimes with an older one). The substitution led to a lot of
brokenness all over the place. It apparently isn't that easy to debug
either.
If we do not insist on lockstep updating of our use of a JS library
we're probably just as well off not using one at all. The easiest way is
to distribute it with the sources, but it may not be the best.
Also, we are under no obligation to stay bleeding edge with whatever JS
library we choose. This is a good thing as we don't need the random
breakage that a "flavor of the month" updating policy would cause.
--
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply [flat|nested] 30+ messages in thread