From: Junio C Hamano <gitster@pobox.com>
Date: Fri, 05 Aug 2016 22:06:28 GMT
Subject: Re: [PATCH v4 11/12] convert: add filter.<driver>.process option
Message-ID: <xmqqfuqivpjv.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <2e13c31c-5ee2-890d-1268-98fb67aba1ea@web.de>

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.