Re: The future of gitweb - part 2: JavaScript

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 [off-list ref] => 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