Re: [Gnu-arch-users] Nit

[Robert Collins]

On Sun, 2003-10-19 at 16:35, Evan Powers wrote:
> In such a situation that pqm might get beaten about pretty hard as every 
> developer and his dog sends merge requests to the pqm. Having to fork/exec 
> tla for every operation wouldn't help.
> 
> Obviously this is not an argument against a CLI interface, and in retrospect 
> this isn't as strong an argument as I had hoped. But I think it at least 
> demonstrates the probable existence of a (not insignificant) problem space 
> where in-process is the better option. I think arch should offer both.

tla doesn't fit the sweet spot (*) for fork/exec volume problems - and I
don't think it ever will for the style of requests a patch manager
handles. 

IMO a CLI suitable for encapsulation is a must, for convenient shell and
the like access. A C api for that only has to be written once, and
likewise for a python api etc etc. In fact, you could use SWIG to
generate N API's from a clean C one. That does beg a question though: if
the C wrappers API is going to be similar to the libarch C API, why
would we bother wrapping the CLI in C at all - why not the CLI API for
CLI scripting, and the C API for everything else?

Their are two sensible answers that come to mind 1): the libarch API may
be to unstable, but the CLI one stable. 2) the challenges in doing a
long lived arch process may be much greater than that in generating an
identical interface that implements via the CLI.

Rob

(*) The sweet spot is the point where the overhead of fork/exec is
comparable to the overhead in delivering the request. I.e. 5% or 10% or
more. Below that, the gains are so indignificant, that better
optimisation in the request delivery is usually an easier target.
-- 
GPG key available at: <http://members.aardvark.net.au/lifeless/keys.txt>.

signature.asc
Description: This is a digitally signed message part