From: Brandon Williams <bmwill@google.com>
To: Stefan Beller <sbeller@google.com>
Cc: Derrick Stolee <stolee@gmail.com>, git <git@vger.kernel.org>
Subject: Re: [RFC] push: add documentation on push v2
Date: Wed, 18 Jul 2018 10:15:12 -0700 [thread overview]
Message-ID: <20180718171512.GC17137@google.com> (raw)
In-Reply-To: <CAGZ79kbLn-uwQOXfqhtO46v0EWevY43Tf4W5Rz9gDD9_qbmX=A@mail.gmail.com>
On 07/18, Stefan Beller wrote:
> On Wed, Jul 18, 2018 at 6:31 AM Derrick Stolee <stolee@gmail.com> wrote:
> >
> > On 7/17/2018 7:25 PM, Stefan Beller wrote:
> > > On Tue, Jul 17, 2018 at 2:09 PM Brandon Williams <bmwill@google.com> wrote:
> > >> Signed-off-by: Brandon Williams <bmwill@google.com>
> > >> ---
> > >>
> > >> 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
next prev parent reply other threads:[~2018-07-18 17:15 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-17 21:09 [RFC] push: add documentation on push v2 Brandon Williams
2018-07-17 23:25 ` Stefan Beller
2018-07-18 13:31 ` Derrick Stolee
2018-07-18 16:56 ` Stefan Beller
2018-07-18 17:15 ` Brandon Williams [this message]
2018-07-20 13:12 ` Jeff Hostetler
2018-07-24 19:00 ` Brandon Williams
2018-07-18 17:11 ` Brandon Williams
2018-07-18 17:19 ` Duy Nguyen
2018-07-18 17:46 ` Brandon Williams
2018-07-18 17:57 ` Duy Nguyen
2018-07-18 17:08 ` Brandon Williams
2018-07-18 18:07 ` Stefan Beller
2018-07-18 18:17 ` Duy Nguyen
2018-07-18 18:21 ` Brandon Williams
2018-07-24 19:28 ` Brandon Williams
2018-07-25 15:15 ` Duy Nguyen
2018-07-25 17:46 ` Brandon Williams
2018-08-02 15:17 ` Duy Nguyen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180718171512.GC17137@google.com \
--to=bmwill@google.com \
--cc=git@vger.kernel.org \
--cc=sbeller@google.com \
--cc=stolee@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.