| 1 |
On Mon, Sep 16, 2013, Rich Freeman wrote: |
| 2 |
> On Mon, Sep 16, 2013 at 7:28 AM, Steven J. Long |
| 3 |
> > It's only an issue at system-level when your code is dependent on what |
| 4 |
> > the higher layer is going to do with your output, or requires a specific |
| 5 |
> > higher layer to run at all(!). |
| 6 |
> |
| 7 |
> I think the real issue is the lack of any kind of standardization |
| 8 |
> around an API for a service manager. For eons there really hasn't |
| 9 |
> been any kind of cross-distro service manager in the first place, |
| 10 |
|
| 11 |
cross-distro is so limited: cross-operating-system is far more flexible and |
| 12 |
shows much more capability and maturity from a developer, in my eyes; and |
| 13 |
openrc has been doing that for quite a while now. |
| 14 |
|
| 15 |
> let alone a standard interface for them. |
| 16 |
|
| 17 |
IDK it's pretty clear what must people want to tell their services to do: |
| 18 |
things like start, stop, reload, check (ie running correctly: eg an httpd |
| 19 |
should respond to GET /), and hooks. Other than that, configuration should |
| 20 |
be declarative, with the option for the admin to modify the execution, |
| 21 |
similar to how a packager patches code. |
| 22 |
|
| 23 |
An API is simply a way to do that from C, which is more relevant nowadays, |
| 24 |
with the event-based approach to hardware activation, cgroup notification |
| 25 |
which can be far more frequent than a sh scripter would be comfortable with, |
| 26 |
and the desire to extend xinetd, as well as incorporate monitoring. |
| 27 |
|
| 28 |
> The vertical integration issues mainly seem to stem from a lack of any |
| 29 |
> kind of abstraction at this layer. |
| 30 |
|
| 31 |
I have to disagree. Sloppy discipline in the craft has got nothing to do |
| 32 |
with an abstraction being available. And inversion of coupling is nothing |
| 33 |
but amateur, not vertical integration. This is not at the boundary between |
| 34 |
the kernel and libc: this is userland, pure and simple. |
| 35 |
|
| 36 |
For a counter-example of how to do it, consider LADSPA [1] and the number |
| 37 |
of successful applications using it, including backends like gstreamer. |
| 38 |
Because the API is deliberately kept simple, it is possible to build a |
| 39 |
higher layer on top of it (ie: vertically integrated, if it cannot work |
| 40 |
with multiple backend libs) eg: DSSI [2] which again is a deliberately |
| 41 |
simple API, providing the UI abstraction for audio plugins. |
| 42 |
|
| 43 |
And both are multi-platform. |
| 44 |
|
| 45 |
The similarity between LADSPA and the rc.h interface, in that regard, is |
| 46 |
striking. |
| 47 |
|
| 48 |
Regards, |
| 49 |
steveL. |
| 50 |
|
| 51 |
[1] http://www.ladspa.org/ |
| 52 |
[2] http://dssi.sourceforge.net/ |
| 53 |
-- |
| 54 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |
Archives