| 1 |
On Mon, 13 Jan 2014 19:27:36 +0100 |
| 2 |
Tom Wijsman <TomWij@g.o> wrote: |
| 3 |
> > Not an API. APIs are bad. What we should have is a good set of |
| 4 |
> > lightweight Unix-friendly command line tools. See, for example, the |
| 5 |
> > "Scripting Commands" section of "man cave". |
| 6 |
> |
| 7 |
> It still is an API that way, just expressed differently |
| 8 |
|
| 9 |
The term "API" seems to mean "library or communication interface" these |
| 10 |
days (see "Git API" and the like). So for clarity, it's probably better |
| 11 |
to make the distinction. |
| 12 |
|
| 13 |
> if you would only do this you're introducing forks where you might |
| 14 |
> not need them. Providing shell commands is one possible binding to |
| 15 |
> the API... |
| 16 |
|
| 17 |
Forks are far less of a big deal than trying to share a process between |
| 18 |
programming languages. This is a *huge* deal when trying to integrate |
| 19 |
modern C++ with languages with primitive thread-hostile runtimes like |
| 20 |
Python and Ruby. |
| 21 |
|
| 22 |
Unless you're doing a heavy GUI (in which case portability probably |
| 23 |
isn't going to cut it anyway, without a far larger API than it's worth |
| 24 |
providing), most of the cost for most of the use cases for this is in |
| 25 |
the PM reading in configs and the like. The way around that is to allow |
| 26 |
communication via pipes, still in a Unix-friendly manner. This can be |
| 27 |
implemented nearly transparently. |
| 28 |
|
| 29 |
-- |
| 30 |
Ciaran McCreesh |
Archives