Meeting: Sept 19, 2008
Topic: A proposal for how a new nsIProcess API will be exposed in javascript
Participating: James Boston (jboston), David Humphrey (humph), Benjamin Smedberg (bsmedberg)
13:04 <@humph> so bsmedberg, we're looking for some ideas on best path forward for james,
with a view to a 1 month milestone, and then 2 more after that, each about
1 month apart
13:04 <@humph> he's looked at the pyhon stuff
13:04 <@humph> python too
13:05 < jboston> I'm sorry I haven't got an api proposal posted somewhere yet.
13:05 <@humph> that will be part of the first one, imo
13:05 < bsmedberg> yep
13:09 < bsmedberg> if you were going to create a standard XPCOM API, you'd want to re-use
nsIInputStream and nsIOutputStream
13:10 <@humph> so you said to focus on JS at first
13:10 <@humph> so does having him work on an IDL to start make the most sense?
13:11 < bsmedberg> anyway, no, I don't think we should focus on IDL
13:11 < bsmedberg> the kind of spec I'd like to see is something like:
13:11 < bsmedberg> /**
13:12 < bsmedberg> * Popen - JS function to launch a process
13:12 < bsmedberg> * @param arguments a string or array of arguments to pass to the program
13:13 < bsmedberg> * @param stdin a string or output stream to provide as the program's stdin
13:13 < bsmedberg> * @param stdout a function which will accept output from the program
13:13 < bsmedberg> * @param stderr a function which will accept error output from the program
13:13 < bsmedberg> */
13:13 < bsmedberg> function Popen(arguments, stdin, stdout, stderr)
13:13 < bsmedberg> / call this function as a constructor, e.g. "new Popen(...)"
13:14 < bsmedberg> I think we should focus on asynchronous behavior
13:14 < bsmedberg> opening program synchronously is uncommon and generally not a good programming
practice anyway
13:15 < jboston> The python example has options for buffered/unbuffered.
13:15 < jboston> Is that useful here?
13:15 < bsmedberg> well... maybe
13:15 < bsmedberg> the python subprocess doesn't use callbacks
13:16 < bsmedberg> it stores the data in a buffer and you have to read from it periodically
13:16 < bsmedberg> it would be a lot simpler to have callbacks for "you've got data" and "the
process finished"
13:17 < bsmedberg> and you can hide the implementation details like polling the pipe on a thread
13:17 < bsmedberg> realistically though, for a first pass you could ignore the pipes altogether
13:17 < bsmedberg> just make a JS API for launching a process
13:18 < bsmedberg> and a callback to notify the client code when the process is done and what the
exit code/status was
13:18 < bsmedberg> and then gradually add features such as support for stdout/stdin
13:18 < jboston> ok
13:19 <@humph> bsmedberg: can you give him an example of a JS API that's doing things at this
level which would be good to learn from, in terms of style, technique, etc.?
13:20 < bsmedberg> see e.g. http://docs.jquery.com/Effects/show#speedcallback
13:20 < bsmedberg> show "blah" and fire a callback when you're done
13:20 <@humph> bsmedberg: good, I'm also thinking of the moz side.
13:21 < bsmedberg> there's probably something in FUEL
13:21 < bsmedberg> but I don't really know it that well
13:21 <@humph> true
13:21 <@humph> we can poke around there
13:22 < bsmedberg> FUEL is crippled by IDL
13:22 < bsmedberg> a little bit
13:22 <@humph> stupid question for a sec, but if we don't go via idl/xpcom, are we using
js-ctypes?
13:22 < bsmedberg> so all of their callbacks are done through fuelIEvents
13:22 < bsmedberg> oh, in terms of *implementation*
13:22 <@humph> yes, sorry
13:22 < bsmedberg> you'll probably want to use standard XPCOM
13:22 <@humph> I wasn't clear
13:22 <@humph> ok, that makes sense
13:23 < bsmedberg> nsIProcessImplementation
13:23 < bsmedberg> which exposes stuff that is then wrapped for easy use by a JS library
13:23 <@humph> right
13:25 < jboston> Does changing nsIProcess break anything else in the mozilla?
13:25 <@humph> you're likely adding here, not changing, no?
13:25 < bsmedberg> there are certainly places in mozilla which use nsIProcess
13:25 < jboston> yes. true.
13:26 < bsmedberg> adding/fixing probably won't break anything
13:26 < bsmedberg> modifying could
13:26 < bsmedberg> there are unresolves issues with character sets...
13:26 < bsmedberg> unresolved, even
13:26 <@humph> freudian slip :)
13:26 < bsmedberg> so we'll have to think about that fairly early
13:27 <@humph> james, do feel like you have enough to go away and start working this up?
13:27 < jboston> Yes.
13:27 <@humph> clearly there is more you'll need to know, but responding to questions becomes
more common place.
13:27 <@humph> mfinkle, ted, and others will be interested in this too
13:28 < jboston> Great.
13:28 < bsmedberg> the JS API design
13:28 < bsmedberg> once it's got a first draft, we should run it by jresig
13:29 <@humph> right. jboston, that's John Resig, creator of JQuery and also moco employee
13:29 < bsmedberg> oh, also: this is the kind of thing that works out really well if you do
test-driven development
13:29 < jboston> Yes.
13:29 <@humph> bsmedberg: what flavour of tests do you recommend for this?
13:29 < bsmedberg> xpcshell probably
13:30 <@humph> jboston: did you see ted's talk on these?
13:30 <@humph> if not we cover them in class too
13:30 < jboston> No. I wasn't at that talk, sorry.
13:30 < bsmedberg> http://developer.mozilla.org/en/Writing_xpcshell-based_unit_tests
13:30 <@humph> ok, we filmed it as well.
13:30 <@humph> and that
13:30 < jboston> super.
13:31 <@humph> bsmedberg: this has been really helpful, thanks very much.
13:31 < jboston> Thank-you!
13:31 <@humph> jboston: kill two birds with one stone:
http://sparc.senecacollege.ca/pub/mozilla.lecture/mozilla-20073/
bsmedberg-xpcom-seneca.avi
13:32 <@humph> meet benjamin + xpcom
13:32 < bsmedberg> lit from an emergency light in the corner of a dark room ;-)
13:32 <@humph> haha
13:32 < jboston> Ok. I think you may have had me watch that in May if it's what I think it is.
The lights go out?
13:32 <@humph> yes. he has that effect.
13:34 <@humph> ok, thanks all. I'll call this meeting a success, and complete.
13:34 < jboston> Yar.
13:35 < bsmedberg> thanks!