From: Jakub Narębski <jnareb@gmail.com>
Date: Sat, 30 Jul 2016 09:32:00 GMT
Subject: Re: [PATCH v2 5/5] convert: add filter.<driver>.process option
Message-ID: <8f40f520-2fa5-449a-57b8-e0fed6b92061@gmail.com>
In-Reply-To: <2435ACEE-19BE-4995-B929-BCEF658F278E@gmail.com>

W dniu 2016-07-30 o 01:44, Lars Schneider pisze:
> On 30 Jul 2016, at 01:11, Jakub Narębski <jnareb@gmail.com> wrote:

>> I think the protocol should be either: <size> + <contents>, or
>> <size unknown> + <contents> + <flush>, that is do not use flush
>> packet if size is known upfront -- it would be a second point
>> of truth (SPOT principle).
>
> As I mentioned elsewhere a <flush> packet is always send right now.
> I have no strong opinion if this is good or bad. The implementation
> was a little bit simpler and that's why I did it. I will implement 
> whatever option the majority prefers :-)

Well, if we treat it as a size hint, then it is all right; as you
say it makes for a simpler implementation: read till flush.  Git
should not error out if there is mismatch between specified and
actual size of return from the filter; filter can do whatever
it wants.

I see there is v3 series sent, so I'll move the discussion there.
One thing: we probably would want for the size / size-hint
packet to be extensible, either

  size=<size> [(SPC <key>=<value>)...] "\n"

or

  <size> [(SPC <sth>)...] "\n"

that is, space separated list starting with size / size hint.

Upfront error could be signalled by putting for example "error"
in place of size, e.g.

  error <error description> "\n"

-- 
Jakub Narębski