Meeting: Sept 19, 2008
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!