Re: [PATCH 3/3] Add sideband status report to git-archive protocol

From: Junio C Hamano <junkio@cox.net>
Date: Sep 10, 2006, 20:31 UTC
Message-ID: <7vr6yjqx9o.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <cda58cb80609101215h36b0f7d7m990ed3011cfda9d2@mail.gmail.com>

"Franck Bui-Huu" <vagabon.xyz@gmail.com> writes:

> We could use a new service flag to ask daemon.c to start the service
> with the sideband multiplexer process already setup and plugged with
> the sercive is going to start ? Hence others future services could use
> it.

We do not know how "future services" would look like, so I do not think it is worth doing so at this moment.

Refactoring existing code after the requirements of the second and subsequent users are identified would result in much nicer outcome with less effort, just like I showed here with the two patches, than overengineering things in advance without knowing what those requirements are to be generic enough.

For example, moving that code to reusable piece (to daemon.c or elsewhere -- it does not make a difference) does not even help a similar code that already exists in upload-pack.c, which needs to monitor multiple processes involved in a pipe and report failure exit of any of them. We would definitely want to have something that can cover both of these existing cases when the next user comes along, and if that next user fits in one of the patterns (either have a pipeline with multiple processes like upload-pack.c does and has to monitor all of them, or just one process which is essentially an internal subroutine call and has to monitor only that process) then refactoring this part right now to cover both cases would make sense but we do not know what that next user will look like.