| 1 |
On Fri, Sep 13, 2013, William Hubbs wrote: |
| 2 |
> OpenRC currently has a public api, consisting of librc and libeinfo |
| 3 |
> (rc.h and einfo.h are the headers); however, I do not know of any |
| 4 |
> released software that uses these, so, if there is nothing, I am |
| 5 |
> considering making this code private to OpenRC and getting rid of the |
| 6 |
> API. |
| 7 |
|
| 8 |
Wow, I didn't realise those were there, at least not as a public API. |
| 9 |
Thanks for bringing them to light. |
| 10 |
|
| 11 |
> I will reconsider if someone tells me there is actual software out |
| 12 |
> there which links to these libraries besides OpenRC, but if there isn't, |
| 13 |
> I am inclined to make all of that code private. |
| 14 |
|
| 15 |
On Sat, Sep 14, 2013, William Hubbs wrote: |
| 16 |
> There may be other reasons to keep the api, that's why I put out the |
| 17 |
> question. |
| 18 |
|
| 19 |
Personally I think they are useful: UberLord must have thought that they |
| 20 |
have wider applicability, eg at the juncture between script and the init-system |
| 21 |
in terms of implementation. It's easy to eg code a lua or python interface |
| 22 |
to the API. It also provides a basis for the things qnikst has been discussing |
| 23 |
in #openrc. |
| 24 |
|
| 25 |
WRT your concern about "vertical integration" I don't think that should be |
| 26 |
a worry. So long as you simply provide the API (which has been stable all |
| 27 |
this time) and make no bones about what a higher layer does with it, you are |
| 28 |
not committing any coupling no-nos. |
| 29 |
|
| 30 |
It's only an issue at system-level when your code is dependent on what the |
| 31 |
higher layer is going to do with your output, or requires a specific higher |
| 32 |
layer to run at all(!). |
| 33 |
|
| 34 |
Regards, |
| 35 |
steveL |
| 36 |
-- |
| 37 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |
Archives