On Aug 11, 2012, at August 11, 20121:06 PM, Marco Rogers <[email protected]> wrote:
> I'm sure there's already a thread with good info about this. But I want to > start a fresh topic. I'm updating a few of my open source libs to be > compatibile with 0.8. And I'm trying to sort out the best way to remain > backwards compatible with 0.6 and ideally 0.4 if possible. I'll just start > with a few targeted questions. This is mostly about child processes for my > procstreams lib. But feel free to use this thread to collect any other useful > compatibility info. First off, cut 0.4. It's not good for the community at this point to support more than the last two stable versions of node.js. Things are still changing fairly dramatically and we need to push everyone towards the latest releases at a reasonable pace. It's our responsibility in the module community to draw some kind of line in the sand for how fast you'll need to upgrade in order to continue to get support. 0.4 will be cut quite soon from request. > > The wiki documenting changes from 0.6 to 0.8 is here. > https://github.com/joyent/node/wiki/API-changes-between-v0.6-and-v0.8 > > 1. Buffer.concat is new and super useful. It's written in pure js so shimming > it is simple. I copied it right out of node source. What do people think of > this? > > https://github.com/polotek/procstreams/blob/master/compat/buffer.js > > I was thinking of putting on npm as something like buffer-compat. Also I've > seen people doing a check for Buffer first like if(typeof Buffer !== > 'undefined'). What's that about? > > 2. One of the significant changes to child processes is that they emit 2 > significant events, "exit" and "close". The semantics of "exit" have changed > slightly and part of them have been shifted to "close". For my procstreams > module this means "close" is now more appropriate where before I had > depending on "exit". > > Compatibility here is tricky because in older version of node "close" isn't > emitted at all. You could conceivably do a version check (version < > 0.7.something) and then forward the "exit" event to "close". Is this the best > method? Is there a recommended way of doing version checks? That sounds reasonable. > > Another issue I have that is specific to procstreams is that I'm blurring the > api between child processes and streams. This raises the problem that "close" > is already an event on streams that are backed by file descriptors, e.g. > sockets and file streams. But there's no good way to tell these special > steams from basic streams that don't emit close. I don't think that's > relevant here, except to say I hope we continue to solidify the stream spec > so that at least this type of thing is easier to reason about. > > The method I'm using to duck type fd streams is by checking whether they have > a method called "destroy". That seems to work pretty okay, but the whole > thing feels brittle; easily broken by changes in implementation. I'm > interested in better ideas if people have them. The solution here is "neither". Your high level object should emit "end" and it should do it only when whatever it's abstracting is truly done. It shouldn't scope directly to the underlying streams end, close or destroy unless that event means that *you* are done with it. Streams are not required to, or insured, to emit either close or destory. > > 3. It seems that child processes also support returning buffers instead of > defaulting to string output. That's nice and I haven't run into any down side > of this yet. Just FYI. > > 4. Custom input/output streams in child processes. I remember a little of the > debate as the custom fds feature was removed from child processes and then > put back in with a different api. I haven't dig into the details here and > haven't had to yet. Any info is appreciated. > > I'm gonna dig through the archives for past threads on this. But if you know > where they are and can link them here, that would be helpful. The idea I have > is to have some targeted modules that enable backwards compatibility like the > buffer-compat I mentioned above. And then maybe collect those into a > node-0.8-compat that folks can pull into their modules as an easy way to try > and support older environments. That may not be feasible. But it's an idea. > > Thanks > :Marco > > -- > Marco Rogers > [email protected] | https://twitter.com/polotek > > Life is ten percent what happens to you and ninety percent how you respond to > it. > - Lou Holtz > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
