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

[Jakub Narebski <jnareb@gmail.com>]

Lea Wiemann wrote:
> 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