Re: The future of gitweb - part 2: JavaScript

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