From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 9D0C81381F3 for ; Wed, 18 Sep 2013 12:00:49 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 18BF0E0B28; Wed, 18 Sep 2013 12:00:38 +0000 (UTC) Received: from smtpout.karoo.kcom.com (smtpout.karoo.kcom.com [212.50.160.34]) by pigeon.gentoo.org (Postfix) with ESMTP id 29B49E0B25 for ; Wed, 18 Sep 2013 12:00:36 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.90,929,1371078000"; d="scan'208";a="33404968" Received: from unknown (HELO rathaus.eclipse.co.uk) ([82.153.102.142]) by smtpout.karoo.kcom.com with ESMTP; 18 Sep 2013 13:00:17 +0100 Date: Wed, 18 Sep 2013 13:05:18 +0100 From: "Steven J. Long" To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] Re: Re: rfc: status of OpenRC's public API Message-ID: <20130918120518.GA10491@rathaus.eclipse.co.uk> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <20130914001606.GA29108@linux1> <20130916112858.GA2825@rathaus.eclipse.co.uk> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Archives-Salt: 05dff215-b8c4-4a3b-9b26-6dfb60d02fb1 X-Archives-Hash: 8024ddd9a7659cac49b85283d8870c63 On Mon, Sep 16, 2013, Rich Freeman wrote: > On Mon, Sep 16, 2013 at 7:28 AM, Steven J. Long > > It's only an issue at system-level when your code is dependent on what > > the higher layer is going to do with your output, or requires a specific > > higher layer to run at all(!). > > I think the real issue is the lack of any kind of standardization > around an API for a service manager. For eons there really hasn't > been any kind of cross-distro service manager in the first place, cross-distro is so limited: cross-operating-system is far more flexible and shows much more capability and maturity from a developer, in my eyes; and openrc has been doing that for quite a while now. > let alone a standard interface for them. IDK it's pretty clear what must people want to tell their services to do: things like start, stop, reload, check (ie running correctly: eg an httpd should respond to GET /), and hooks. Other than that, configuration should be declarative, with the option for the admin to modify the execution, similar to how a packager patches code. An API is simply a way to do that from C, which is more relevant nowadays, with the event-based approach to hardware activation, cgroup notification which can be far more frequent than a sh scripter would be comfortable with, and the desire to extend xinetd, as well as incorporate monitoring. > The vertical integration issues mainly seem to stem from a lack of any > kind of abstraction at this layer. I have to disagree. Sloppy discipline in the craft has got nothing to do with an abstraction being available. And inversion of coupling is nothing but amateur, not vertical integration. This is not at the boundary between the kernel and libc: this is userland, pure and simple. For a counter-example of how to do it, consider LADSPA [1] and the number of successful applications using it, including backends like gstreamer. Because the API is deliberately kept simple, it is possible to build a higher layer on top of it (ie: vertically integrated, if it cannot work with multiple backend libs) eg: DSSI [2] which again is a deliberately simple API, providing the UI abstraction for audio plugins. And both are multi-platform. The similarity between LADSPA and the rc.h interface, in that regard, is striking. Regards, steveL. [1] http://www.ladspa.org/ [2] http://dssi.sourceforge.net/ -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)