Closed Bug 484246 Opened 15 years ago Closed 2 years ago

Implement a replacement for nsIProcess

Categories

(Core :: XPCOM, enhancement)

x86
All
enhancement
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: jboston, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.0.7) Gecko/2009021906 Firefox/3.0.7
Build Identifier: 

Replace the existing nsIProcess interface with new interface that:
* supports Unicode on all platforms
* supports piping to/from processes
* can handle asynchronous I/O via callbacks
* is available through FUEL (Firefox User Extension Library)
 

Reproducible: Always
Summary: Implement a replace for nsIProcess → Implement a replacement for nsIProcess
As noted in design emails, I don't want the primary API to be an XPCOM interface. Instead, it should be a JS API that happens to be implemented partly using XPCOM under the covers.

Not sure what you mean about FUEL: I think this should be made available through Components.utils.import("resource://gre/process.js") or a similar JS module approach.
Status: UNCONFIRMED → NEW
Ever confirmed: true
The Python subprocess module is good prior art:
http://docs.python.org/3.0/library/subprocess.html

I find it easy to use for a variety of things, and I wish Gecko's process spawning was half as nice.
Just going to wave bug 68702 around as a previous attempt at the IPC stuff, just FYI.
The interface https://developer.mozilla.org/En/NsIProcess is unfrozen, so it might be extended to provide the io streams and to support transparent encoding character to that character set expected by the operating system. I'm not sure whether this is always unicode. I.e. if I transfer a file path via command parameter to a process it may be totaly confused and not find the file, if the path contains umlauts on MacOS X. The encoding is tricky, because it decomposes umlauts into ligatures and then encodes this as MacRoman. The encoding of the parameters expected by MacOS is not unicode.

To make the js side of the interface platform independent, the correct encoding to what the platform expects (may be unicode or what ever) should be done transparently inside the interface.

For my own project getting as soon as possible the facilities to feed stdin of the process and to read from stdout and stderr of the process asynchronous i.e. to evaluate the verbose status information of long running sub processes to animate the progress bar etc. is important, because I want to use XulRunner to build the GUI for a testing tool, which should configure the test environment and then launch the application to be tested and feed it with input and test it's results. Without this interface enhancement this can not be done interactive i.e. if the test candidate outputs a message requesting for input, this requires this interface enhancement.

If the disk burning tool requests for inserting a new disk and then hit a key, this also requires this interface enhancement. At the moment I can use the disk burning tool only to create disk images, because this works not interactive and can be done using the existing interface, but burning disks is interactive and therefore can not be done using the existing implementation of that interface.
There's a couple of issues around Unicode to sort out. For instance, path/filenames, arguments passed to processes, and the STDOUT of processes are three different problems that will have their own edge cases and platform specific quirks.
May be we find inside Trolltech QT some inspiration how to solve these problems in a way that is transparent to the JavaScript side.

Special handling for arguments representing a file path may be realized by not specifying the string with the path but specifying a nsILocalFile as argument instead, which would give the interface a chance to recognize this argument as something that needs to be handled special to convert the path of that nsILocalFile to a string as it is expected by the launched process.

When rethinking the interface we may also with to optionally fire a JavaScript event, when an asynchronous process finished. At the moment I have to poll periodically the isRunning property to detect whether it is still running or has finished. But if I provide an event handler the interface might inform me automatically when the process finished.
Georg, the runAsync API already allows you to get a notification when the process completes. It's on nsIProcess on trunk, nsIProcess2 on the 1.9.1 branch.
Assignee: nobody → jamesboston
Status: NEW → ASSIGNED
Now this has been assigned, what does this mean to me during your time of developing the new interface implementation? Should I wait with pulling from hg trunk until you invite for testing your new implementation, or is it save for my application to continue pulling from trunk and using the interface?

(In reply to comment #7)
> Georg, the runAsync API already allows you to get a notification when the
> process completes. It's on nsIProcess on trunk, nsIProcess2 on the 1.9.1
> branch.

Ah, I see you recently updated the documentation.
(In reply to comment #8)
> Now this has been assigned, what does this mean to me during your time of
> developing the new interface implementation? Should I wait with pulling from hg
> trunk until you invite for testing your new implementation, or is it save for
> my application to continue pulling from trunk and using the interface?

The new interface will (I believe) be in addition to the existing nsIProcess interfaces. Also nothing will likely land on trunk until it is ready for use.
(In reply to comment #8)

None of the work on this bug will appear in trunk until it is submitted here as a patch and passed a review. I don't have a patch ready for review, but if you are interested in following my progress I have some links for you.

A project page wiki:
http://zenit.senecac.on.ca/wiki/index.php/User:Jamesboston/nsIProcess

My mercurial server:
http://hg.jamesboston.ca/mozilla/gsoc/
Is there any chance that this interface can be extended to allow one to set environment variables?  That would be very handy for my lcgi extension (http://github.com/RufusHamade/lcgi/) and would save me the effort of trying to implement the current hacky wrapper scripts on Windows.

If you haven't got time to implement that, I could always give it a go.  Assuming you and others think it is a good idea.  I was thinking of extending nsIProcess/nsIProcess2 with setEnviron() (and perhaps getEnviron()) methods to be called between init() and run(), but wouldn't want to do so without some chance of getting it committed.
@James

As you are already extending nsIProcess, would it be possible to rewrite run, so that it takes an (optional) working directory? Using the Mozilla Framework, it is currently not possible to run executables that need to have a working directory set for loading up config-files - well they will run but immediately close themselves, depending on how they have been programmed.

This could also be used to fix Bug 290735.

What do you think?

Cheers!
Mr. Boston, per your hg repository, it's been a couple months since you last worked on it.  Can you give us an idea what work still remains?

My primary interest is in using a XULRunner app to remote-control other applications - interacting with them while they're running.
At present, I have something that captures the output of program. It can't send data the program. It can't send/receive interactively. It doesn't allow for a callback to be executed on the captured output. I haven't sorted out any of the problems with character sets. And, such as it is, it's a linux only solution. A significant amount of work remains.
What is the current status of this bug? When can we expect the first code peices in official mercurial repository to build our own XulRunner with at least buggy implementation of the new interface?
Is it true that progress has halted on these nsiProcess changes?  If so, would it be possible for me to take on at least part of the work?

I'm mostly interested in two aspects:
 - The ability to control the subprocess's environment
 - Access to stdin/stdout/stderr for the subprocess.  

Looking at the nsIProcess interface and underlying infrastructure - at least on Unix (PR_CreateProcess) and MacOS (posix_spawnp) - suggests that it would be relatively straightforward to extend the existing nsIProcess interface with these features.

(Assuming I took this on, would any Mozilla engineers be willing to mentor and/or review these changes?  Should I raise separate bugzilla bugs to cover this work?)
A lot of this work is already in progress in bug 68702, please see the patches and commentary there.

The bug assignee didn't login in Bugzilla in the last 7 months.
:nika, could you have a look please?
For more information, please visit auto_nag documentation.

Assignee: jamesboston → nobody
Status: ASSIGNED → NEW
Flags: needinfo?(nika)

We don't expose legacy xul addons anymore, so this isn't relevant anymore.

Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(nika)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.