The future of gitweb (long term goals)

The future of gitweb (long term goals)

[Jakub Narebski]

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.

Gitweb was created by Kay Sievers in 2005[1][2], and was initially
developed in a separate repository, as a separate tool.  Since 0a8f4f0
(Merge git://git.kernel.org/pub/scm/git/gitweb, 2006-06-10) it got
merged into git (so git 1.4.0 included gitweb)... and gitweb didn't
really have a maintainer since (at least not official one).

[1] http://kerneltrap.org/node/5026
[2] http://kerneltrap.org/node/5059

The code got cleaned up since original version, static files got
separated out of gitweb script, gitweb acquired its Makefile... still
gitweb doesn't really have clear long-term plans for the future, nor
does it have a mission statement.

I think that we should discuss what we want gitweb to be.


Current requirements are:
- Perl 5.8.x (for proper Unicode / UTF-8 support)
- core Perl modules: CGI, Encode, Fcntl, File::Find, File::Basename,...
- non-core Perl modules optional, needed for some of extra features
- backward compatibility (query params and path_info URLs)
- easy installation even without admin rights
- scanning for repositories (as an option)
- lightweight

Which of those requirements should be preserved, and which can be
safely abandoned?


Lack of backward compatibility with respect to gitweb links was, if I
remember it correctly, one of reasons why http://git.kernel.org didn't
move to other web interface like cgit.  So abandoning this requirement
is a bit no.

Another feature that made cgit unsuitable for git.kernel.org was IIRC
the fact that cgit doesn't support (or didn't support then; I don't
know the current feature set of cgit) scanning for repositories,
without need for list of repositories to be generated by separate tool
or script.  So the mode where gitweb scans for repositories (where
$projects_list is a directory) is here to stay.


The most restrictive requirement is to use only core Perl modules (in
core as of Perl version 5.8.3 or something) for main functionality;
non-core Perl modules are currently allowed only as optional modules
required for extra (not compulsory) features.

This means that we are not able to use web (micro)framework, or use
templating engine to create HTML instead of combination of CGI.pm
methods and handcrafted HTML (worrying about proper escaping), or just
use CGI::Cache or Plack::Middleware::Cache for adding output caching
to gitweb.  Though if one wants web interface in Perl that uses web
framework (and is supposedly backwards-compatible with gitweb URLs),
there is always Gitalist which uses Catalyst web framework.

On the other hand requiring non-core Perl modules means that gitweb
installation would be harder.  We can work around this issue if there
are a few small such modules (e.g. using Exception::Class or
HTTP::Exception as base class for gitweb error handling) by putting
them in 'inc/' and installing local version if they are not present,
like Git.pm does with local Error.pm module.  But for microframework,
or templating engine, or e.g. Plack (if we go the route to make gitweb
PSGI application) this would be rather out of question.  Anyway, in
any case gitweb would probably require more complicated build system
than current one... but moving to e.g. ExtUtils::MakeMaker shouldn't
be that hard (see how Git.pm does it, only we can require Perl 5.8.3
which has new enough EU::MM that supports DESTDIR).


There are also few "1.7.5" things, i.e. issues that needs to be done
but does not affect backwards compatibility, and doesn't change
current gitweb requirements any.  They are about making gitweb easier
to maintain and more perl-ish.

1. Splitting gitweb into modules (packages), for better maintainability.

   As I wrote earlier in "[PATCH 0/2] gitweb: Begin splitting gitweb"[3]
   gitweb with 25K lines and 220K bytes begins to be a bit unwieldy to
   maintain.  Therefore the proposal to split it into modules 
(packages).

   The difficult part is deciding on how gitweb would search for those
   modules (see [3] for discussion), and what the modules should be:
   how to group subroutines and variables, and how to name packages.

   There is also a question whether to split gitweb all at once (like
   in original attempt by Pavan during GSoC2010), or just split-off
   modules piece by piece, in incremental way.  I think the second one
   (evolutionary) has a better chance for success.

   [3] http://thread.gmane.org/gmane.comp.version-control.git/165824

2. Default installation directories, installation configurability.

   This issue is somewhat connected to the previous one; the ability
   to install gitweb modules in arbitrary directory doesn't make sense
   if you can't configure to be installed gitweb to find them.

   There is also a question whether gitweb modules should be installed
   by default alongside gitweb, or together with other Perl modules
   i.e. like Git.pm from 'perl/'.

3. Gitweb documentation: move away from gitweb/README

   Currently gitweb documentation can be found in gitweb/README,
   gitweb/INSTALL and in comments in gitweb script.  While
   gitweb/README is not largest (on my system largest is
   sendmail-cf/README), and not even largest in git repository
   (t/README is larger), it is nevertheless one of larger READMEs.

   Perhaps it would be good idea to generate gitweb(1) manpage,
   either from gitweb/gitweb.txt, Documentation/gitweb.txt (in
   AsciiDoc), or like for Git.pm from gitweb/gitweb.perl (in POD),
   (after splitting both gitweb.perl and Gitweb.pm would get separate
   manpages), or from gitweb/gitweb.pod (also POD, but separate)?
   What do you think?

4. Build procedure - move to using ExtUtils::MakeMaker, like Git.pm

   Some of proposed changes, both those preserving and those not
   preserving backward compatibility, would need more sophisticated
   build system.  I am talking here about depending on non-core Perl
   modules (with or without bundling some version of them in 'inc/'),
   and building manpages and HTML gitweb documentation out of POD.

   I think it would be much easier to do that using EU::MM, like
   Git.pm does... only because gitweb requires at least Perl 5.8.0,
   we can assume that EU::MM is new enough that it support DESTDIR
   mechanism.

-- 
Jakub Narębski
ShadeHawk on #git

Re: The future of gitweb (long term goals)

[Michael J Gruber]

Jakub Narebski venit, vidit, dixit 14.02.2011 20:39:
> 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.
...
> Current requirements are:
> - Perl 5.8.x (for proper Unicode / UTF-8 support)
> - core Perl modules: CGI, Encode, Fcntl, File::Find, File::Basename,...
> - non-core Perl modules optional, needed for some of extra features
> - backward compatibility (query params and path_info URLs)

I'd second that this is important for adaption by some main users.

> - easy installation even without admin rights
> - scanning for repositories (as an option)
> - lightweight

All of these are important for instaweb also. I consider instaweb a very
underrated feature! (It also needs some works of love, not just
appreciation, of course.)

> 1. Splitting gitweb into modules (packages), for better maintainability.

Also, this may help including other optional parts. The graph viewer as
used on repo.or.cz sets gitweb apart from quite a few alternatives and
would be used more widely if it were an optional module shipping with
gitweb. Just imagine instaweb with graphs ;)
Also, being part of gitweb, the viewer may attract a few coders.

Michael

Re: The future of gitweb (long term goals)

[Jakub Narebski]

On Tue, 15 Feb 2011, Michael J Gruber wrote:
> Jakub Narebski venit, vidit, dixit 14.02.2011 20:39:

> > 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.
> ...
> > Current requirements are:
> > - Perl 5.8.x (for proper Unicode / UTF-8 support)
> > - core Perl modules: CGI, Encode, Fcntl, File::Find, File::Basename,...
> > - non-core Perl modules optional, needed for some of extra features
> > - backward compatibility (query params and path_info URLs)
> 
> I'd second that this is important for adaption by some main users.

You mean here backward compatibility of API (i.e. old links keep working),
isn't it?

> > - easy installation even without admin rights
> > - scanning for repositories (as an option)
> > - lightweight
> 
> All of these are important for instaweb also. 

Nowadays git-instaweb uses _installed_ gitweb, so neither easy 
installation, nor installing / running without admin rights is necessary
for use of gitweb in git-instaweb.  Strictly speaking neither is scanning
for repositories; I think git-isnatweb could generate file with list of
repositories (with repository) to show.

> I consider instaweb a very
> underrated feature! (It also needs some works of love, not just
> appreciation, of course.)

Beside adding support for new web servers (like recently added 'plackup'),
what do you thing needs to be done?

> > 1. Splitting gitweb into modules (packages), for better maintainability.
> 
> Also, this may help including other optional parts. The graph viewer as
> used on repo.or.cz sets gitweb apart from quite a few alternatives and
> would be used more widely if it were an optional module shipping with
> gitweb. Just imagine instaweb with graphs ;)
> Also, being part of gitweb, the viewer may attract a few coders.

Well, adding anything major (like e.g. write functionality, output caching;
perhaps graph of history is also in this category) really require split
gitweb.  It is getting hard to maintain gitweb as it is now.

-- 
Jakub Narebski
Poland

Re: The future of gitweb (long term goals)

[Ævar Arnfjörð Bjarmason]

On Mon, Feb 14, 2011 at 20:39, Jakub Narebski <jnareb@gmail.com> wrote:
> This means that we are not able to use web (micro)framework, or use
> templating engine to create HTML instead of combination of CGI.pm
> methods and handcrafted HTML (worrying about proper escaping), or just
> use CGI::Cache or Plack::Middleware::Cache for adding output caching
> to gitweb.  Though if one wants web interface in Perl that uses web
> framework (and is supposedly backwards-compatible with gitweb URLs),
> there is always Gitalist which uses Catalyst web framework.
>
> On the other hand requiring non-core Perl modules means that gitweb
> installation would be harder.  We can work around this issue if there
> are a few small such modules (e.g. using Exception::Class or
> HTTP::Exception as base class for gitweb error handling) by putting
> them in 'inc/' and installing local version if they are not present,
> like Git.pm does with local Error.pm module.  But for microframework,
> or templating engine, or e.g. Plack (if we go the route to make gitweb
> PSGI application) this would be rather out of question.  Anyway, in
> any case gitweb would probably require more complicated build system
> than current one... but moving to e.g. ExtUtils::MakeMaker shouldn't
> be that hard (see how Git.pm does it, only we can require Perl 5.8.3
> which has new enough EU::MM that supports DESTDIR).

Why do you think that if we use larger modules these things would get
harder?

There's already applications on the CPAN which can do "fat
packing". I.e. you could use Plack, Catalyst, Template and whatever
else but run some make target to pack gitweb and all its dependencies
into a single file.

Obviously it would be really big, and probably slow unless you ran it
as a fastcgi script. But that would be a tradeoff for making the
source easier to maintain.

But packing things like these is not a technical challange at all, and
probably way easier than reinventing the wheel each time you need some
small thing that's not in core, but is in a popular & well tested CPAN
module.

Re: The future of gitweb (long term goals)

[Jakub Narebski]

On Tue, 22 Feb 2011, Ævar Arnfjörð Bjarmason wrote:
> On Mon, Feb 14, 2011 at 20:39, Jakub Narebski <jnareb@gmail.com> wrote:

> > This means that we are not able to use web (micro)framework, or use
> > templating engine to create HTML instead of combination of CGI.pm
> > methods and handcrafted HTML (worrying about proper escaping), or just
> > use CGI::Cache or Plack::Middleware::Cache for adding output caching
> > to gitweb.  Though if one wants web interface in Perl that uses web
> > framework (and is supposedly backwards-compatible with gitweb URLs),
> > there is always Gitalist which uses Catalyst web framework.
> >
> > On the other hand requiring non-core Perl modules means that gitweb
> > installation would be harder.  We can work around this issue if there
> > are a few small such modules (e.g. using Exception::Class or
> > HTTP::Exception as base class for gitweb error handling) by putting
> > them in 'inc/' and installing local version if they are not present,
> > like Git.pm does with local Error.pm module.  But for microframework,
> > or templating engine, or e.g. Plack (if we go the route to make gitweb
> > PSGI application) this would be rather out of question.  Anyway, in
> > any case gitweb would probably require more complicated build system
> > than current one... but moving to e.g. ExtUtils::MakeMaker shouldn't
> > be that hard (see how Git.pm does it, only we can require Perl 5.8.3
> > which has new enough EU::MM that supports DESTDIR).
> 
> Why do you think that if we use larger modules these things would get
> harder?

I mean here that while it makes sense to bundle some version of required
modules in e.g. 'gitweb/inc/' (or 'perl/inc/') in gitweb sources if there
are few small self-contained modules (like e.g. Try::Tiny, or
Capture::Tiny), I don't think that bloating git repository with Perl
dependencies would be a good idea.

Well, we could get them from CPAN during build if they are not present,
and/or download them and include in generated tarball...

> There's already applications on the CPAN which can do "fat
> packing". I.e. you could use Plack, Catalyst, Template and whatever
> else but run some make target to pack gitweb and all its dependencies
> into a single file.
> 
> Obviously it would be really big, and probably slow unless you ran it
> as a fastcgi script. But that would be a tradeoff for making the
> source easier to maintain.

Well, I know of two such modules: App::FatPack and PAR... neither of which
is in core.  But the issue is not with installing or bundling modules
when they are present, I think; we can always install modules alongside
gitweb in 'lib/' subdirectory, even if you don't have admin rights to
install those required modules system-wide.
 
And there is also local::lib, though the problem is that it is web server
user account that has to have path to Perl modules set up correctly.

> But packing things like these is not a technical challange at all, and
> probably way easier than reinventing the wheel each time you need some
> small thing that's not in core, but is in a popular & well tested CPAN
> module.

Well, there already exists Gitalist, which is Perl web interface to git
repositories, which uses Catalyst MVC web framework (and which purposedly
is backwards compatible with gitweb URLs, though I am not sure about 
path_info-based ones).

There is a question of balance (minimal dependencies or not reinventing
the wheel) and choice (which of types of server to support: CGI, FastCGI,
mod_perl, PSGI; what templating engine to use: Template Toolkit, 
Template::Xslate, Tenjin, Template::Declare / Markapl, Template::Semantic
and HTML::Zoom, Template::Moustache; what framework or microframework
to use: Mojolicus, Dancer, Web::Simple, Catalyst, Jifty, CGI::Application,
Mason, etc.).

-- 
Jakub Narebski
Poland

Re: The future of gitweb (long term goals)

[Michael J Gruber]

Jakub Narebski venit, vidit, dixit 21.02.2011 23:06:
> On Tue, 15 Feb 2011, Michael J Gruber wrote:
>> Jakub Narebski venit, vidit, dixit 14.02.2011 20:39:
> 
>>> 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.
>> ...
>>> Current requirements are:
>>> - Perl 5.8.x (for proper Unicode / UTF-8 support)
>>> - core Perl modules: CGI, Encode, Fcntl, File::Find, File::Basename,...
>>> - non-core Perl modules optional, needed for some of extra features
>>> - backward compatibility (query params and path_info URLs)
>>
>> I'd second that this is important for adaption by some main users.
> 
> You mean here backward compatibility of API (i.e. old links keep working),
> isn't it?

Yep, the last item.

> 
>>> - easy installation even without admin rights
>>> - scanning for repositories (as an option)
>>> - lightweight
>>
>> All of these are important for instaweb also. 
> 
> Nowadays git-instaweb uses _installed_ gitweb, so neither easy 
> installation, nor installing / running without admin rights is necessary
> for use of gitweb in git-instaweb.  Strictly speaking neither is scanning
> for repositories; I think git-isnatweb could generate file with list of
> repositories (with repository) to show.

Cool, I didn't know, but it's a great feature.
By "easy installation" I mean being able to use it without having to
configure a "central" web server, i.e. just the way a git+gitweb in
$HOME can run instaweb without admin rights.

>> I consider instaweb a very
>> underrated feature! (It also needs some works of love, not just
>> appreciation, of course.)
> 
> Beside adding support for new web servers (like recently added 'plackup'),
> what do you thing needs to be done?

E.g., using an installed gitweb - I just learned it does that already!

Also, the graph viewer, i.e. including it as a module with the same
"looks" as the rest of gitweb.

I don't know how customisable gitweb's layout is right now (CSS). That
might be important for some. Personally, whenever I'm on the more
"modern" repo hosters, I'm longing for the clean interface and high
information density of gitweb.

>>> 1. Splitting gitweb into modules (packages), for better maintainability.
>>
>> Also, this may help including other optional parts. The graph viewer as
>> used on repo.or.cz sets gitweb apart from quite a few alternatives and
>> would be used more widely if it were an optional module shipping with
>> gitweb. Just imagine instaweb with graphs ;)
>> Also, being part of gitweb, the viewer may attract a few coders.
> 
> Well, adding anything major (like e.g. write functionality, output caching;
> perhaps graph of history is also in this category) really require split
> gitweb.  It is getting hard to maintain gitweb as it is now.

100% agreed. Also, smaller modules make it easier for new gitweb
contributors to join and help.

Cheers,
Michael

The future of git-instaweb (was: Re: The future of gitweb (long term goals))

[Jakub Narebski]

On Wed, 23 Feb 2011, Michael J Gruber wrote:
> Jakub Narebski venit, vidit, dixit 21.02.2011 23:06:
>> On Tue, 15 Feb 2011, Michael J Gruber wrote:
>>> Jakub Narebski venit, vidit, dixit 14.02.2011 20:39:
>> 
>>>> 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.
>>> ...
>>>> Current requirements are:
[...]
>>>> - easy installation even without admin rights
>>>> - scanning for repositories (as an option)
>>>> - lightweight
>>>
>>> All of these are important for instaweb also. 
>> 
>> Nowadays git-instaweb uses _installed_ gitweb, so neither easy 
>> installation, nor installing / running without admin rights is necessary
>> for use of gitweb in git-instaweb.  Strictly speaking neither is scanning
>> for repositories; I think git-isnatweb could generate file with list of
>> repositories (with repository) to show.
> 
> Cool, I didn't know, but it's a great feature.
> By "easy installation" I mean being able to use it without having to
> configure a "central" web server, i.e. just the way a git+gitweb in
> $HOME can run instaweb without admin rights.

Yes, the idea of git-instaweb is to be able to run browser with gitweb
showing current repository, which means running some kind of web server.
Selected web server is run in "user mode", with config file generated
by git-instaweb, and with port number > 1024 (so non-root can open it).
Web server can be installed system-wide by administrator (for example
apache or lighttpd), or installed locally (for example plackup with
local::lib).

>>> I consider instaweb a very
>>> underrated feature! (It also needs some works of love, not just
>>> appreciation, of course.)
>> 
>> Beside adding support for new web servers (like recently added 'plackup'),
>> what do you thing needs to be done?
> 
> E.g., using an installed gitweb - I just learned it does that already!

This (git-isnatweb using installed gitweb) has its advantages and
disadvantages.

Pro:
~~~~
The main reason behind changing git-instaweb so it uses installed gitweb
(after 'install-gitweb' target was added to git Makefile, of course) in 
c0cb4ed (git-instaweb: Configure it to work with new gitweb structure, 
2010-05-28) was to be able to use git-instaweb with split gitweb.  This
commit by Pavan Kumar Sunkara was part of ultimately failed Google Summer
of Code 2010 project that was meant to add ability to edit repositories
to gitweb, of which first part was splitting gitweb into modules (packages)
for better maintability.

Second reason was to avoid duplication of disk space: generated
git-instaweb script included the whole gitweb.cgi script, and some of its
static files like e.g. gitweb.css.

Contra:
~~~~~~~
This change means that git-instaweb requires gitweb to be installed to work.
(Of course gitweb can be installed locally, and you can configure 
git-instaweb to use specified version of gitweb / specified gitweb script.)

There is also issue of packaging and dependencies: e.g. should git-instaweb
be a part of gitweb RPM package?

> Also, the graph viewer, i.e. including it as a module with the same
> "looks" as the rest of gitweb.

Errr, I think this is to be gitweb feature, rather than git-instaweb
feature.  Don't you agree?

> I don't know how customisable gitweb's layout is right now (CSS). That
> might be important for some.

You can change CSS, you can add additional CSS files (e.g. change default
font size) quite easily.

> [...]                        Personally, whenever I'm on the more 
> "modern" repo hosters, I'm longing for the clean interface and high
> information density of gitweb.

OTOH high information density (and lots of hyperlinks) make for steeper
learning curves, while adding power.

>>>> 1. Splitting gitweb into modules (packages), for better maintainability.
>>>
>>> Also, this may help including other optional parts. The graph viewer as
>>> used on repo.or.cz sets gitweb apart from quite a few alternatives and
>>> would be used more widely if it were an optional module shipping with
>>> gitweb. Just imagine instaweb with graphs ;)
>>> Also, being part of gitweb, the viewer may attract a few coders.
>> 
>> Well, adding anything major (like e.g. write functionality, output caching;
>> perhaps graph of history is also in this category) really require split
>> gitweb.  It is getting hard to maintain gitweb as it is now.
> 
> 100% agreed. Also, smaller modules make it easier for new gitweb
> contributors to join and help.

Right.

-- 
Jakub Narebski
Poland

The future of gitweb - part 2: JavaScript

[Jakub Narebski]

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

* 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

Re: The future of gitweb - part 2: JavaScript

[Michał Łowicki]

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

Re: The future of gitweb - part 2: JavaScript

[david]

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

Re: The future of gitweb - part 2: JavaScript

[Peter Vereshagin]

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

Re: The future of gitweb - part 2: JavaScript

[Pau Garcia i Quiles]

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)

Re: The future of gitweb - part 2: JavaScript

[Jakub Narebski]

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

Re: The future of gitweb - part 2: JavaScript

[Peter Vereshagin]

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

Re: The future of gitweb - part 2: JavaScript

[Jakub Narebski]

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

Re: The future of gitweb - part 2: JavaScript

[Peter Vereshagin]

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

Re: The future of gitweb - part 2: JavaScript

[Jakub Narebski]

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

Re: The future of gitweb - part 2: JavaScript

[Jakub Narebski]

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

Re: The future of gitweb - part 2: JavaScript

[Peter Vereshagin]

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

Re: The future of gitweb - part 2: JavaScript

[Jakub Narebski]

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

Re: The future of gitweb - part 2: JavaScript

[Jakub Narebski]

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

Re: The future of gitweb - part 2: JavaScript

[Pau Garcia i Quiles]

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)

Re: The future of gitweb - part 2: JavaScript

[Petr Baudis]

  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.

Re: The future of gitweb - part 2: JavaScript

[Jakub Narebski]

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

Re: The future of gitweb - part 2: JavaScript

[Petr Baudis]

  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.

Re: The future of gitweb - part 2: JavaScript

[Jakub Narebski]

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

Re: The future of gitweb - part 2: JavaScript

[Jakub Narebski]

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

Gitweb != HTTP back-end {Was: Re: The future of gitweb - part 2: JavaScript}

[Drew Northup]

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

Re: The future of gitweb - part 2: JavaScript

[Drew Northup]

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

Re: Gitweb != HTTP back-end {Was: Re: The future of gitweb - part 2: JavaScript}

[Jakub Narebski]

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