Re: [PATCH v2 5/5] convert: add filter.<driver>.process option
- From
Jakub Narębski <jnareb@gmail.com>
- Date
- Jul 30, 2016, 09:32 UTC
- 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:
Show 9 quoted lines
>> 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