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 ;-)
