[PATCH 2 of 3 side-word (+4)] sshpeer: use a 'bufferedinputpipe' for standard output of the ssh process

[Pierre-Yves David]

On 06/02/2015 07:11 AM, Yuya Nishihara wrote:
> On Mon, 01 Jun 2015 17:03:01 -0700, Pierre-Yves David wrote:
>> On 06/01/2015 04:57 PM, Augie Fackler wrote:
>>> On Mon, Jun 01, 2015 at 09:12:31AM -0700, Pierre-Yves David wrote:
>>>> On 06/01/2015 08:16 AM, Yuya Nishihara wrote:
>>>>> On Mon, 1 Jun 2015 08:01:55 +0900, Yuya Nishihara wrote:
>>>>> This will slightly complicate doublepipe, so I'm not sure which is better.
>>>>
>>>> The original version was doing all in one. However, the buffer version using
>>>> the 'os' module is isolated into the 'util' module (we avoid any 'os' usage
>>>> in any top module) and the douple pipe which enforce the ssh specific logic
>>>> of "forward stderr as 'remote:' output" live in the ssh specific 'sshpeer'
>>>> module.
>
> I see.
>
>>>> Do you want me to update the commit message?
>>>
>>> I think that might help future code archaeologists, so let's go for yes?
>>>
>>> At this point we've got enough going on I'm having trouble keeping up
>>> with all the churn at the protocol-ish layers, so I'm sure in two
>>> years we'll be grateful for overly-verbose commit messages.
>>
>> Do you want that at documentation for each class as a details in the
>> description for the each commit introducting them ?
>>
>>>> (note: at some point we will replace all this with thread).
>>>
>>> Would we be better off to just code that up now? It might be
>>> significantly simpler...
>>
>> The current approach just replace on of the core object with something
>> that behave exactly the same but also unsure the server output is
>> consume in real time. This have ø impact on the rest of the code. The
>> object itself is non trivial but the impact on the code is ultra simple.
>> translating all that to threading have a much bigger impact and will be
>> much more complexe. We'll eventually get to there for bundle2 but I
>> would be happy to not be rabbit-holed with a massive refactor for a bug
>> fix that is definitely not on my critical path.
>
> Maybe I'm noob, I don't see the point why we want to move to threading at
> some time. (except that we can't do select() on Windows)

Moving to threading would allow use to stream a bundle out, while 
receiving a bundle in. (or even non bundle thing) allowing more powerful 
and faster interaction.

It would also requires less hack with pipe and buffer.


-- 
Pierre-Yves David