[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Nit
From: |
Evan Powers |
Subject: |
Re: [Gnu-arch-users] Nit |
Date: |
Sun, 19 Oct 2003 02:35:00 -0400 |
User-agent: |
KMail/1.5.4 |
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
- Re: [Gnu-arch-users] Nit, (continued)
- Re: [Gnu-arch-users] Nit, Robert Collins, 2003/10/22
- Re: [Gnu-arch-users] Nit, Tom Lord, 2003/10/21
- Re: [Gnu-arch-users] Nit, Andrew Suffield, 2003/10/21
- Re: [Gnu-arch-users] Nit, Tom Lord, 2003/10/20
- Re: [Gnu-arch-users] Nit, Thomas Zander, 2003/10/20
- Re: [Gnu-arch-users] Nit, Samium Gromoff, 2003/10/20
- Re: [Gnu-arch-users] Nit, Charles Duffy, 2003/10/20
- Re: [Gnu-arch-users] Nit, Mark A. Flacy, 2003/10/19
- Re: [Gnu-arch-users] Nit,
Evan Powers <=
- Re: [Gnu-arch-users] Nit, Robert Collins, 2003/10/19
- Re: [Gnu-arch-users] Nit, Tom Lord, 2003/10/19
- Re: [Gnu-arch-users] Nit, Mark A. Flacy, 2003/10/19
- [Gnu-arch-users] Re: Nit, Miles Bader, 2003/10/19
- [Gnu-arch-users] Re: Nit, Mark A. Flacy, 2003/10/19
- [Gnu-arch-users] Re: Nit, Miles Bader, 2003/10/19
- Re: [Gnu-arch-users] Re: Nit, Charles Duffy, 2003/10/20
- Re: [Gnu-arch-users] Re: Nit, Mark A. Flacy, 2003/10/20
- Re: [Gnu-arch-users] Nit, Charles Duffy, 2003/10/19
- [Gnu-arch-users] Java and arch, Mark A. Flacy, 2003/10/20