Re: [WIP RFC 2/5] Documentation: add Packfile URIs design doc

From: Jonathan Tan <jonathantanmy@google.com>
Date: Feb 19, 2019, 20:10 UTC
Message-ID: <20190219201022.237430-1-jonathantanmy@google.com>
In-Reply-To: <CAP8UFD0VPZEhBTUb--n5RHECUkO81aPcGkTYGi0fqd35rnKr3Q@mail.gmail.com>

Show 10 quoted lines

> > Good points about SSH support and the client needing to control which
> > protocols the server will send URIs for. I'll include a line in the
> > client request in which the client can specify which protocols it is OK
> > with.
> 
> What if a client is ok to fetch from some servers but not others (for
> example github.com and gitlab.com but nothing else)?
> 
> Or what if a client is ok to fetch using SSH from some servers and
> HTTPS from other servers but nothing else?

The objects received from the various CDNs are still rehashed by the client (so they are identified with the correct name), and if the client is fetching from a server, presumably it can trust the URLs it receives (just like it trusts ref names, and so on). Do you know of a specific case in which a client wants to fetch from some servers but not others? (In any case, if this happens, the client can just disable the CDN support.)

Show 19 quoted lines

> I also wonder in general how this would interact with promisor/partial
> clone remotes.
> 
> When we discussed promisor/partial clone remotes in the thread
> following this email:
> 
> https://public-inbox.org/git/20181016174304.GA221682@aiede.svl.corp.google.com/
> 
> it looked like you were ok with having many promisor remotes, which I
> think could fill the same use cases especially related to large
> objects.
>
> As clients would configure promisor remotes explicitly, there would be
> no issues about which protocol and servers are allowed or not.
> 
> If the issue is that you want the server to decide which promisor
> remotes would be used without the client having to do anything, maybe
> that could be something added on top of the possibility to have many
> promisor remotes.

It's true that there is a slight overlap with respect to large objects, but this protocol can also handle large sets of objects being offloaded to CDN, not only single ones. (The included implementation only handles single objects, as a minimum viable product, but it is conceivable that the server implementation is later expanded to allow offloading of sets of objects.)

And this protocol is meant to be able to use CDNs to help serve objects, whether single objects or sets of objects. In the case of promisor remotes, the thing we fetch from has to be a Git server. (We could use dumb HTTP from a CDN, but that defeats the purpose in at least one way - with dumb HTTP, we have to fetch objects individually, but with URL support, we can fetch objects as sets too.)