Re: The future of gitweb - part 2: JavaScript

[Peter Vereshagin <peter@vereshagin.org>]

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