Re: Revamping the git protocol
- From
Petr Baudis <pasky@suse.cz>
- Date
- Oct 21, 2005, 01:04 UTC
- Message-ID
- <20051021010429.GC30889@pasky.or.cz>
- In-Reply-To
- <4357BCBC.1020706@zytor.com>
Dear diary, on Thu, Oct 20, 2005 at 05:50:20PM CEST, I got a letter where "H. Peter Anvin" <hpa@zytor.com> told me that...
> Another issue is that currently there is no error information propagated > back to the client; the server logs an error in its own logs, but the > client is simply disconnected.
Yes. I agree that while it seems quite complex compared to what we have now, your proposal has good points. But if we are going with the challenge-response at all and if we are going with the simple form, I was merely trying to make sure that it is as compatible as possible.
> Anyone noticed that either of those schemes aren't actually > backward-compatible in any way (old client talking to new server will be > disconnected), and that unfortunately is the best thing one can do with > the current setup, exactly because there is no option negotiation phase?
Yes, option negotiation would solve this for us. But my scheme _is_ backwards-compatible in the way that new client taking to old server will not be disconnected, so it's 50% better than the original proposal.
But I think that considering the long run, we should either not do this challenge-response thing at all, and fix the problem by other (Linus') means, or go for the "complex" scheme. I'd prefer the latter - sending the error messages to the client alone is a huge improvement.
-- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ VI has two modes: the one in which it beeps and the one in which it doesn't.