On 07/18, Stefan Beller wrote: > On Wed, Jul 18, 2018 at 6:31 AM Derrick Stolee <stolee@xxxxxxxxx> wrote: > > > > On 7/17/2018 7:25 PM, Stefan Beller wrote: > > > On Tue, Jul 17, 2018 at 2:09 PM Brandon Williams <bmwill@xxxxxxxxxx> wrote: > > >> Signed-off-by: Brandon Williams <bmwill@xxxxxxxxxx> > > >> --- > > >> > > >> Since introducing protocol v2 and enabling fetch I've been thinking > > >> about what its inverse 'push' would look like. After talking with a > > >> number of people I have a longish list of things that could be done to > > >> improve push and I think I've been able to distill the core features we > > >> want in push v2. > > > It would be nice to know which things you want to improve. > > > > Hopefully we can also get others to chime in with things they don't like > > about the existing protocol. What pain points exist, and what can we do > > to improve at the transport layer before considering new functionality? > > Another thing that I realized last night was the possibility to chunk requests. > The web of today is driven by lots of small http(s) requests. I know our server > team fights with the internal tools all the time because the communication > involved in git-fetch is usually a large http request (large packfile). > So it would be nice to have the possibility of chunking the request. > But I think that can be added as a capability? (Not sure how) Fetch and push requests/responses are already "chunked" when using the http transport. So I'm not sure what you mean by adding a capability because the protocol doesn't care about which transport you're using. This is of course unless you're talking about a different "chunking" from what it means to chunk an http request/response. -- Brandon Williams
