[TOPIC 09/11] Bundle-URI on fetch / resume-able clone

[Taylor Blau <me@ttaylorr.com>]

Bundle-URI on fetch / resume-able clone
=======================================

(moderator: Toon; notetaker: Taylor)

* Toon: we have bundle-uris, which allow us to download bundles before
	cloning. What would it take to do them on fetch, too?
* Toon: Complex; you might end up downloading a lot of bundles that you
	don't need.
* Toon: there was a bundle token that could be used by the client to
	determine whether or not it needs the bundle. Unfortunately, since you
	don't know what amount of history you're missing, the bundle in and of
	itself may not be sufficient.
* Toon: How do we make bundles more efficient on fetch and aware of what
	the clients do and don't have.
* Johannes: In VFS for Git, the set of bundles is "opinionated" and
	regenerated often (e.g., weekly, daily, hourly, etc.). We don't really
	care about oversharing, because it's fast enough to download those
	static files.
* Toon: That's true for the server, not for a singular client.
* Johannes: right, but it's to protect the server. If you don't care
	about having too-big of a bundle, it's OK because you can just fetch
	the last hour and then see what you still need on top of that.
* Johannes: there is logic to determine what you need to download based
	on the time that you last fetched, etc.
* Elijah: are they thin packs? Yes.
* Patrick: the heuristics that we have to advertise what kind of bundles
	are on the server is not sufficient enough to determine which bundles
	the client may or may not want to download. The client must guess.
* Jonathan: ISTM that the property list for the bundles as they are
	today should probably be considered a starting point (as in "part of a
	feature"). The heuristics need to be extended.
* Jonathan: at Google we use packfile-URIs, and one of the advantages of
	how that works is that since the packfiles are advertised after the
	normal fetch negotiation, you get a curated list. For bundle-uris,
	need something analogous to the fetch negotiation for the client to be
	able to make a similar decision of which bundle to download.
* brian: extending the feature to store timestamps, then you could store
	the last fetch on the system would inform some better selection of
	which bundles to clone down during a fetch.
* brian: Would make a big difference for folks in environments which do
	not benefit from reliable Internet connections.
* Toon: Sure... but you have to put a lot of pressure to keep those
	bundles up-to-date on the server side.
* Jonathan: one of the advantages of bundles over packs is that they
	have information about the references. One potential property could be
	"here's the length of this header" and then having the client download
	it to examine whether or not it wants such a bundle.
* Patrick: probably would want to cache those on the client so that
	we're able to avoid re-downloading these every single time.
* Toon: resumability
* Jonathan: protocol supports it, just hasn't been implemented. Someone
	needs to just get it done. :)
* Beyond that, the main complication is how you store the state and what
	the UX is for resuming. But a person implementing it can figure those
	things out.
* Brian: broken-proxy situations require some configurability of where
	your bundles can be downloaded from.