From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 05 08:53:02 2017 Received: (at 27155) by debbugs.gnu.org; 5 Jun 2017 12:53:03 +0000 Received: from localhost ([127.0.0.1]:56595 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dHrVG-0004i0-KF for submit@debbugs.gnu.org; Mon, 05 Jun 2017 08:53:02 -0400 Received: from sender-of-o51.zoho.com ([135.84.80.216]:21095) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dHrVE-0004he-DA for 27155@debbugs.gnu.org; Mon, 05 Jun 2017 08:53:00 -0400 Received: from localhost (port-92-200-94-239.dynamic.qsc.de [92.200.94.239]) by mx.zohomail.com with SMTPS id 1496667174194614.686956108927; Mon, 5 Jun 2017 05:52:54 -0700 (PDT) User-agent: mu4e 0.9.18; emacs 25.2.1 From: Ricardo Wurmus To: 27155@debbugs.gnu.org Subject: Re: bug#27155: [PATCH 0/2] Support service extensions on the "final" service values X-URL: https://elephly.net X-PGP-Key: https://elephly.net/rekado.pubkey X-PGP-Fingerprint: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC Date: Mon, 05 Jun 2017 14:52:50 +0200 Message-ID: <87mv9m7g0t.fsf@elephly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ZohoMailClient: External X-Spam-Score: -1.8 (-) X-Debbugs-Envelope-To: 27155 Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.8 (-) I think it is useful to have the ability to add rewriters at the end of service composition. In my opinion it is always good to have an escape hatch, and this seems to fit the bill. But I agree that it is not an elegant solution, and I wouldn’t want to advocate using it. As to your second idea: it seems tedious for service writers to have to anticipate the ways in which services could be extended (here given by providing extension points). Would it make more sense to allow *extensions* to specify how they should be applied rather than letting services define extension points? This would shift the burden away from services to service extensions. Extensions would still need to provide a way of extending the parent service, but this could be optional. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net