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

> Torsten Bögershausen <tboegi@web.de> writes:
>
>> On 2016-08-03 18.42, larsxschneider@gmail.com wrote:
>>> The filter is expected to respond with the result content in zero
>>> or more pkt-line packets and a flush packet at the end. Finally, a
>>> "result=success" packet is expected if everything went well.
>>> ------------------------
>>> packet:          git< SMUDGED_CONTENT
>>> packet:          git< 0000
>>> packet:          git< result=success\n
>>> ------------------------
>> I would really send the diagnostics/return codes before the content.
> I smell the assumption "by the time the filter starts output, it
> must have finished everything and knows both size and the status".
>
> I'd prefer to have a protocol that allows us to do streaming I/O on
> both ends when possible, even if the initial version of the filters
> (and the code that sits on the Git side) hold everything in-core
> before starting to talk.
>
>>> If the result content is empty then the filter is expected to respond
>>> only with a flush packet and a "result=success" packet.
>> ...
>> Which may be:
>>
>> packet:          git< result=success\n
>> packet:          git< SMUDGED_CONTENT
>> packet:          git< 0000
>>
>> or for an empty file:
>>
>> packet:          git< result=success\n
>> packet:          git< SMUDGED_CONTENT
>> packet:          git< 0000
> The above two look the same to me.