Re: [Gnu-arch-users] Nit

[Evan Powers]

On Saturday 18 October 2003 10:43 pm, Tom Lord wrote:
> > From: Colin Walters <address@hidden>
> > It would be way better to just make libarch be friendly to
> > wrapping by other programming languages.
>
> I wonder what I can do to disabuse you of this mistaken notion.
>
> Hmm.   Why do we have processes at all?   Why not just run everything,
> os to apps, in one big process?

What?

Oh. You're referring to your preference for CLI-style rather than 
library-API-style interfaces to arch, and pointing out that a CLI interface 
doesn't tie arch to any specific scripting language?

Looks like Colin just replied to your post. I'm not sure you'll like his 
Python-exceptions argument, so I'll offer up another one.

An analogy: there are two ways to serve PHP pages with Apache; you can use PHP 
via CGI, or you can use mod_php. I would say the CGI version has a lot in 
common with interfacing with arch via the CLI, and mod_php has a lot in 
common with what Colin (I think) wants, an in-process arch API.

While I agree with you that the CLI interface deserves pursuit, and is 
probably sufficient for much (say, 75%, with absolutely no justification for 
that number) of the extension-language problem space, there are situations 
where an in-process API would be extremely advantageous.

To use Colin's patch queue manager as an example, suppose that GCC (or an even 
better example, the Linux kernel) starts using arch. All of the core 
developers have their own repositories, of course, but they want to provide a 
single centralized repository, managed by the pqm, which tracks everybody's 
changes simultaneously and provides something convenient for people to track 
with their own arch repositories, much as they might currently be tracking 
CVS HEAD.

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.

Evan