Re: [PATCH] gitweb: return correct HTTP status codes

From: Jakub Narebski <jnareb@gmail.com>
Date: Jun 17, 2008, 22:54 UTC
Message-ID: <200806180054.33490.jnareb@gmail.com>
In-Reply-To: <48583A73.7020508@gmail.com>

Lea Wiemann wrote:

Show 7 quoted lines

> Jakub Narebski wrote:
> >
> > But that means checking arguments in the "fast path", which means
> > additional calls to git commands in the _common_ case, not only in
> > the case of errors.
> 
> No, it doesn't, it just pipes stuff into cat-file --batch-check,

Ah, O.K., it does add additional call to git command, which should not matter much performance wise on sane operating systems; it would matter on OS with slow fork, like MS Windows, if gitweb ran on Windows (perhaps it can, but certainly not with ActiveState Perl, IIRC).

But what are arguments for "check params; run command" vs "run command; check params if error" proposed by Junio? Why do you want to check parameters upfront? Does it make code much, much easier?

> which has to be opened on virtually any call to gitweb.

IIRC it is for checking parameters? Even then, using it only on "slow patch", i.e. in preence of error might be better solution.

Or is it needed for something else too?

> Before telling me about the performance of my code, can you please
> (a) read it [...]

By the way, would you be sending your current WIP for review?

P.S. I wanted to ask in another subthread if adding object oriented interface (wrapper) to git repositories (similar to the one used by StGIT / git-python perhaps?) is really needed for implementing gitweb caching?; I still think that you have to chose which spots to cache, and do it from gitweb, and not cache everything. But if it is needed for sane error reporting, and perhaps better ETags...

-- 
Jakub Narebski
Poland