Re: [PATCH v4 11/12] convert: add filter.<driver>.process option

From: Jeff King <peff@peff.net>
Date: Aug 8, 2016, 15:02 UTC
Message-ID: <20160808150255.2otm3z5fluimpiqw@sigill.intra.peff.net>
In-Reply-To: <A07BE78B-5A5D-41F1-A51B-5C71F3E86CCF@gmail.com>

On Sat, Aug 06, 2016 at 08:19:28PM +0200, Lars Schneider wrote:

Show 14 quoted lines

> > I dunno. It's not _that_ big a deal to code around. I was just surprised
> > not to see an up-front status when responding to a request. It seems
> > like the normal thing in just about every protocol I've ever used.
> 
> Alright. The fact that it "surprised" you is a bad sign. 
> How about this:
> 
> Happy answer:
> ------------------------
> packet:          git< status=accept\n
> packet:          git< SMUDGED_CONTENT
> packet:          git< 0000
> packet:          git< status=success\n
> ------------------------

I notice that the status pkt-lines are by themselves. I had assumed we'd be sending other data, too (presumably before, but I guess possibly after, too). Something like:

  git< status=accept
  git< 0000
  git< SMUDGED_CONTENT
  git< 0000
  git< status=success
  git< 0000

I don't have any particular meta-information in mind, but I thought stuff like the tentative "size" field would be here.

I had imagined it at the front, but I guess it could go in either place. I wonder if keys at the end could simply replace ones from the beginning (so if you say "foo=bar" at the front, that is tentative, but if you then say "foo=revised" at the end, that takes precedence).

And so the happy answer is really:

  git< status=success
  git< 0000
  git< SMUDGED_CONTENT
  git< 0000
  git< 0000  # empty list!

i.e., no second status. The original "success" still holds.

And then:

> Happy answer with no content:
> ------------------------
> packet:          git< status=success\n
> ------------------------

This can just be spelled:

  git< status=success
  git< 0000
  git< 0000   # empty content!
  git< 0000   # empty list!

> Rejected content:
> ------------------------
> packet:          git< status=reject\n
> ------------------------

I'd assume that an error status would end the output for that file immediately, no empty lists necessary (so what you have here). I'd probably just call this "error" (see below).

Show 7 quoted lines

> Error during content response:
> ------------------------
> packet:          git< status=accept\n
> packet:          git< HALF_WRITTEN_ERRONEOUS_CONTENT
> packet:          git< 0000
> packet:          git< status=error\n
> ------------------------

And then this would be:

  git< status=success
  git< 0000
  git< HALF_OF_CONTENT
  git< 0000
  git< status=error
  git< 0000

And then you have only two status codes: success and error. Which keeps things simple.

There's one other case, which is when the filter dies halfway through the conversation, like:

  git< status=success
  git< 0000
  git< CONTENT
  git< 0000
  ... EOF on pipe ...

Any time git does not get the conversation all the way to the final flush after the trailers, it should be considered an error (because we can never know if the filter was about to say "whoops, status=error").

-Peff