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

[Drew Northup <drew.northup@maine.edu>]

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