| 1 |
On Fri, Apr 13, 2001 at 09:20:03AM -0600, Daniel Robbins wrote: |
| 2 |
> > To recap, the idea was to have a C/C++ program listen on a pipe, then have |
| 3 |
> > interfaces (in the language of your choice) do things like |
| 4 |
> > "echo packagename>/thatpipe" - the backend would listen and install the package. |
| 5 |
> |
| 6 |
> One problem with this solution is that we need a robust and feature-rich two-way |
| 7 |
> communications stream. For example, your request to install "foo/bar-1.0" may be |
| 8 |
> answered by a list of dependencies that must be satisfied before installation is |
| 9 |
> possible, or a particular dependency that couldn't be satisfied (if it's auto-resolving |
| 10 |
> dependencies), or that the particular package wasn't found in the portage database. |
| 11 |
> |
| 12 |
> With such a system as you describe, the Portage response would have to be placed |
| 13 |
> in another file, and tying these two files into a communications stream would become |
| 14 |
> tricky enough to make this a less-than-elegant, solution. IMO. |
| 15 |
> |
| 16 |
|
| 17 |
Well, the backend program *does* have both a stdin and stdout stream, |
| 18 |
which would provide the two way communication stream you're talking |
| 19 |
about. And we could also set up a socket file if necessary. Or even |
| 20 |
unix sockets (but I think that would be overkill...) |
| 21 |
|
| 22 |
Pete |
Archives