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.
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? 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. 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
