Re: [GSoC] Discuss: Implement support for reftables in ‘dumb’ HTTP transport

From: Patrick Steinhardt <ps@pks.im>
Date: Mar 21, 2024, 13:02 UTC
Message-ID: <Zfwv24OnsD0pDQ7D@tanuki>
In-Reply-To: <xmqqa5n1ak1f.fsf@gitster.g>

On Wed, Mar 13, 2024 at 02:39:24PM -0700, Junio C Hamano wrote:

Show 15 quoted lines

> Aryan Gupta <garyan447@gmail.com> writes:
> 
> > In simple
> > words what I understand is I just need to add support for the server
> > side nothing is to be done for the client side.
> 
> Hmph.  The "dumb" transport is kept primarily to allow folks, who
> can only use web hosting that serves nothing but static files, to
> publish their repositories, and requiring more things to be done on
> the "dumb" server side sounds somewhat backwards to me.
> 
> To be quite honest, I personally doubt that this topic makes much
> sense in this age and day---I've felt that the dumb HTTP walker
> outlived its usefulness for the past 10 years already.  But perhaps
> I am biased by the first-world access to the internet?

Even though I proposed this project in the first place I don't disagree with you. The dumb HTTP protocol is indeed quite esoteric nowadays, and if we want to put it officially into "maintenance" mode then I would not mind to drop that proposed project.

The reason why I added this project is that I found it to be interesting as a thought experiment. The reason why we have "info/refs" is to help out clients of the dumb HTTP transport to figure out actual refs in the repository because they typically live in many separate files. But what I realized is that we don't actually need it with the reftable format anymore because we basically already have a definitive list of all files that a client needs to download to acquire all refs: "tables.list".

So theoretically speaking we can implement support for dumb HTTP with reftables by having the client download "tables.list" and then fetch all the "*.ref" files listed in it. Whether that is sensible may be a different question.

Anyway. If we think that the dumb HTTP protocol extension is dumb then I'd rather want to pull the plug on the proposed GSoC project now rather than later to not lead down potential contributors the wrong path. But in that case I think we might want to make the deprecated state of that protocol official.

Patrick