User:Jamesboston/nsIProcess/meeting-092208

Meeting: Sept 22, 2008
Subject: nsIProcess API
Peoples: James Boston (jboston), David Humphrey (humph), Mark Finkle (mfinkle)

21:10 <@humph> I love designing apis--something about my personality that loves to imitate.
21:10 <@humph> I'd study some great js apis
21:10 <@humph> spend some time steeped in jquery and friends
21:12 < jboston> Ok. I'm just not sure about this callback thing. I haven't figured out if the code waits for the
                 callback before resuming.
21:12 <@humph> http://log.ometer.com/2008-09.html#7
21:13 <@humph> the point of a callback is 'no'
21:13 < jboston> Ah!
21:19 < mfinkle> jboston: about the nsIProcess stuff
21:19 < jboston> yes?
21:19 < mfinkle> nsIProcess is a frozen interface, unlikely you will be able to add, rename or remove methods from
                 it
21:19 < jboston> Is it?
21:19 < mfinkle> but you could try to get nsIProcess2 added for thew APIs
21:20 <@humph> that's a great ellision
21:20 < mfinkle> jboston: http://mxr.mozilla.org/mozilla-central/source/profile/public/nsIProfile.idl#61
21:20 <@humph> mfinkle: did you read his conversation with bsmedberg?
21:20 < mfinkle> no
21:20 < mfinkle> where?
21:21 <@humph> via http://jamesboston.ca/cms/node/65
21:21 <@humph> hrm, I'm wroing
21:21 <@humph> where is it james?
21:22 < jboston> Says here unfrozen: http://developer.mozilla.org/En/NsIProcess
21:22 < mfinkle> lies
21:22 < mfinkle> the source is always the source
21:22 < jboston> Ah! The source is the documentation. First rule of open source.
21:22 < mfinkle> have no fear, I still expect you can do what you need to do
21:23 < mfinkle> just not exactly the way you originally thought
21:23 <@humph> jboston: we need that conversation!
21:23 <@humph> no, this doesn't thwart us
21:23 < jboston> http://zenit.senecac.on.ca/wiki/index.php/User:Jamesboston/nsIProcess/meeting-092008
21:23 <@humph> benjamin has plans to prosper and not to hurt
21:23 < mfinkle> jboston: and if bsmedberg says the sky is yellow... I can be made to believe it too
21:24 <@humph> "It's never enough to say that a world has a green moon.  You must write a world that can only have
               a green moon." (J.R.R. Tolkien)
21:24 <@humph> and so, nsIProcess turned yellow
21:25 <@humph> mfinkle: fuel makes an appearance
21:26 < mfinkle> "nsIProcessImplementation", "adding/fixing probably won't break anything, modifying could"
21:26 <@humph> right
21:26 < mfinkle> so, yeah - think of a nice way to use from JS
21:26 < mfinkle> and worry about IDL second
21:26 < jboston> Ok. So put everything in a new API.
21:26 < mfinkle> but IDL won't be modifying nsIProcess
21:27 < mfinkle> jboston: as for JS yes
21:27 < mfinkle> but to implement it, you make need 2 interfaces (IMO)
21:27 < jboston> So make an nsIProcessImplementation api when I get to the idl?
21:27 < jboston> or nsIProces2
21:27 < mfinkle> fixing nsIProcess and nsIProcess2 (which has new stuff)
21:27 < mfinkle> and by "new stuff" I mean API's that can't fit into the current nsIProcess
21:28 < jboston> ok. I've started patching nsIProces already to make it work.
21:28 < jboston> It's really the ipc stuff that's missing from the current api.
21:29 < mfinkle> jboston: ARG! I gave you a link to nsIProfile, nsIProcess is not frozen
21:29 < mfinkle> so we can worry less
21:30 < mfinkle> jboston: but patching current nsIProcess to get it's implementation working correctly is a great
                 first step
21:34 < mfinkle> jboston: another thing - since nsIProcess already has a "run", consider keeping it instead of
                 switching to "open" (from https://wiki.mozilla.org/NsIProcess)
21:34 < mfinkle> as long as it doesn't cause pain
21:34 < jboston> Ok. That makes sense.
21:35 < mfinkle> when overriding a method to take more params, we can use "optional" IDL
21:36 < mfinkle> or make a different method, like runWithOutput(...)
21:36 <@humph> does run return a pid?
21:36 < mfinkle> that is just in the IDL
21:36 <@humph> or could it?
21:36 <@humph> I don't have the idl in front of me
21:36 < mfinkle> it does return a PID
21:37 < mfinkle> well, it has the signature to return a PID
21:37 < mfinkle> most times, the impl does not
21:37 <@humph> it doesn't , but it could, ok
21:37 < mfinkle> right
21:38 < jboston> Right now the nsIProces object doesn't keep the pid. That's what my first patch fixes.
21:39 < jboston> You can't implement kill or a lot of the other methods without it.
21:40 < mfinkle> jboston: also note that you can derive an IDL interface from another IDL interface
21:40 < mfinkle> like nsILocalFile deriving from nsIFile
21:40 <@humph> from one other
21:40 <@humph> good idea
21:40 < mfinkle> nsIProcess2 could derive from nsIProcess
21:41 < mfinkle> nsIProcess2 would have all the new methods
21:41 < jboston> Ok. That would be useful.
21:41 < mfinkle> therefore no code would get broken
21:41 < mfinkle> if someone wanted to do something neat with the new API they would:
21:41 < mfinkle> var process2 = process.QueryInterface(Ci.nsIProcess2);
21:44 <@humph> only down side here is that you start to inherit your api a lot vs. starting new
21:44 <@humph> but yeah, this is what needs to happen
21:44 <@humph> at least, part of what needs to happen
21:47 < jboston> mfinkle: Thanks for the direction.
21:48 < mfinkle> jboston: no prob - but this is just the XPCOM/IDL part
21:48 < mfinkle> sounds like bsmedberg would like to see a nifty FUEL or pure JS code module for this too
21:48 < mfinkle> which would hide some of the XPCOM
21:49 < jboston> Yes. It would be nice to have an simpler way to use this stuff.
21:49 <@humph> mfinkle: I still lack a good example of what he means by that
21:49 < mfinkle> sounds like he wants to look to other scripting langs (like python and ruby) for guidance and ideas
                 as to what such a library would do and act
21:50 < mfinkle> like: process.run(..., myJSCallback)
21:50 < mfinkle> so the process starts and runs async
21:50 <@humph> yeah, sure
21:50 <@humph> but I mean, is there something like this living in the tree now?
21:50 < mfinkle> when it finishes it will call myJSCallback with the output
21:50 < mfinkle> humph: nope
21:51 < mfinkle> we have nothing to give the  output of a process
21:51 <@humph> not a process, sorry
21:51 < mfinkle> technically, | process.run(..., myJSCallback) | could be done very easily in IDL too
21:51 <@humph> what I mean is a js code module
21:52 < mfinkle> some
21:52 < mfinkle> http://mxr.mozilla.org/mozilla-central/find?text=&kind=text&string=.jsm