[nodejs] [ANN] AwsSum v0.11.0 - with complete docs on the the new site

Hi everyone, I'm again proud to announce a new version of AwsSum - v0.11.0 - a complete library for talking to Amazon APIs (25 services). You guys are great with bug reports and corner cases so thanks to everyone who helped with this release - it makes the library more complete and more stable wit

Re: [nodejs] HA / failover support

I wrote a blog post related to this a few weeks ago exploring what can be done from a deployment & uptime POV regarding node [[ http://blog.evantahler.com/production-deployment-with-node-js-clusters ]] In a nutshell, you can use the native cluster module to manage a number of workers which han

Re: [nodejs] Re: Keeping semantics in your version numbers, i.e. please don't release major version zero

On 9/20/12 2:30 PM, Scott González wrote: On Thu, Sep 20, 2012 at 2:27 PM, Austin William Wright mailto:diamondma...@users.sourceforge.net>> wrote: The problem comes in when I or other developers want to /use/ those libraries, and keep them up-to-date. You can't use features like "~1".

Re: [nodejs] Re: Keeping semantics in your version numbers, i.e. please don't release major version zero

Well then you have no need for version numbers at all, what are you complaining about? Some of us, however, do rely on upgrading packages. Some of use multiple packages that require() the same module, we need a way to resolve which package is mutually compatible. You can't make broad assumption

Re: [nodejs] Re: Keeping semantics in your version numbers, i.e. please don't release major version zero

> You want to update to the latest package that's compatible with your current version. I don't understand why you would want to do that. You are taking a risk for no reason. I only update when I need a feature or some bug is discovered. In either case I may need to change my code or may not.

Re: [nodejs] Re: Keeping semantics in your version numbers, i.e. please don't release major version zero

I never said you need to trust the library developer, but that's no excuse for them to mis-identify which versions are breaking, and which are stable. You want to update to the latest package that's compatible with your current version. What's the easiest way to do that? I should not need to tr

Re: [nodejs] Re: Keeping semantics in your version numbers, i.e. please don't release major version zero

> developers should be able to identify at a glance which version is breaking, and which is not You sure have a lot of faith in the developers. I would never trust any version numbering scheme. When I need a new feature or a bug-fix I test the latest version. I don't even pay attention to versi

Re: [nodejs] Re: Keeping semantics in your version numbers, i.e. please don't release major version zero

For production applications, having tests and maintaining dependencies is a good idea. However I explained this isn't a replacement for the major version number: (1) Not everyone is writing production applications. My own ~0 application in production moves too fast for tests to be meaningful.

Re: [nodejs] Re: Keeping semantics in your version numbers, i.e. please don't release major version zero

Semver used by most all the packages that I depend on. The problem is that (1) most of these dependencies are on ~0 and feel free to break their API any time without warning (this is what they tell me), and (2) those that don't use semver, *don't disclose any scheme at all.* It is not documented

Re: [nodejs] Re: Keeping semantics in your version numbers, i.e. please don't release major version zero

I'll apply my same thinking under Rails/rubygems/bundler to node/npm. I don't ever look at version numbers of gems I use, or NPM modules now that I've started doing some node too. I install them, version control them and write tests. If my app works with the dependencies at the versions I instal

Re: [nodejs] Re: Keeping semantics in your version numbers, i.e. please don't release major version zero

I don't disagree with you insofar as using something that *looks like *semver without *being *semver can be confusing. However, what I do disagree with is the attitude that we should change *common practice* because there is a similar-looking *standard*. Does that make sense? It's one thing to be

[nodejs] Re: http_parser HPE_INVALID_CHUNK_SIZE errors after upgrading to node 0.8

As a follow-up, it looks like the data I get back from the response often has "\r\n2000\r\n" in the middle of what otherwise looks like good data, so I'm guessing something is going wrong with processing multi-part (chunked? whatever is the right term?) responses, and it sometimes reads too much

Re: [nodejs] Re: Keeping semantics in your version numbers, i.e. please don't release major version zero

I guess that's what I'm advocating against: Using some scheme without any documentation of it makes your program unpredictable. And not just runtime unpredictable (at least we can always refer to the ultimate documentation, the source code), but we don't know how well it will upgrade in the futu

Re: [nodejs] Re: Keeping semantics in your version numbers, i.e. please don't release major version zero

I think one way we disagree is in the definition of "standard". All npm guarantees is that the version by *parseable* by node-semver, not that they follow the complete semver specification. It may not be a documented "standard", but what Tim alludes to, architecture-change.breaking-change.non-brea

Re: [nodejs] Re: Keeping semantics in your version numbers, i.e. please don't release major version zero

Actually, I don't tag my dependencies like that either, I use Git submodules, so I know exactly, byte-for-byte what code I'm distributing. This doesn't eliminate the need for upgrading packages from time to time. I need to be able to run an "git node update" command and have 20 packages update,

[nodejs] http_parser HPE_INVALID_CHUNK_SIZE errors after upgrading to node 0.8

We're trying migrating from node 0.6.21 to 0.8.9, and one of our processes that does a database backup (a couple million items fetched over HTTP and HTTPS from Amazon SimpleDB and DynamoDB APIs) has started getting "HPE_INVALID_CHUNK_SIZE" errors, presumably from node's http_parser.c (and then

Re: [nodejs] Re: Keeping semantics in your version numbers, i.e. please don't release major version zero

> 2. Migrate from architecture-change.breaking-change.non-breaking-change numbers to breaking-change.non-breaking-feature-addition.bug-fix numbers. I realized, I haven't seen this scheme before today, at least not as you explain. It *seems* to explain why people are hesitant to release a versio

Re: [nodejs] Re: Keeping semantics in your version numbers, i.e. please don't release major version zero

On Thu, Sep 20, 2012 at 2:25 PM, Austin William Wright wrote: > If more than a dozen people are using your package, then next time you make > a breaking change, release 1.0.0. Continue to clearly identify when you make > breaking changes, when you release new features, and when you release a > pat

Re: [nodejs] Re: Keeping semantics in your version numbers, i.e. please don't release major version zero

If more than a dozen people are using your package, then next time you make a breaking change, release 1.0.0. Continue to clearly identify when you make breaking changes, when you release new features, and when you release a patch. That'd help tremendously with the package ecosystem, I believe.

Re: [nodejs] Re: Keeping semantics in your version numbers, i.e. please don't release major version zero

Certainly making a distinction between an architectural change/rewrite is important for many reasons. But I don't think it's a distinction we need to split out in the version number. Developers are more inclined to be able to use out-of-bound information than the program, for example, we unders

Re: [nodejs] Re: Keeping semantics in your version numbers, i.e. please don't release major version zero

On Thu, Sep 20, 2012 at 3:10 PM, Austin William Wright < diamondma...@users.sourceforge.net> wrote: > The API *does not need to be *what you definitely want. If you decide to > later change the API, just release 2.0.0. The important part is that you > tell us clearly that the API broke. That's all

Re: [nodejs] Re: Keeping semantics in your version numbers, i.e. please don't release major version zero

The API *does not need to be *what you definitely want. If you decide to later change the API, just release 2.0.0. The important part is that you tell us clearly that the API broke. That's all that matters. On Thursday, September 20, 2012 12:04:10 PM UTC-7, Scott González wrote: > > On Thu, Sep

Re: [nodejs] Re: Keeping semantics in your version numbers, i.e. please don't release major version zero

On Thu, Sep 20, 2012 at 2:59 PM, Austin William Wright < diamondma...@users.sourceforge.net> wrote: > Also if you're releasing versions with a 0. prefix then what's the point? > You're dropping the indication of new feature releases, just so you can > have a leading 0.? This inconsistency is confu

Re: [nodejs] Re: Keeping semantics in your version numbers, i.e. please don't release major version zero

The problem is packages don't use this consistently, and don't even make an effort to tell us of breaking changes. 0.x.x is supposed to mean, and often does mean, the package is in a period of rapid API breakage. But many packages simply use it as an excuse to break their API whenever they want.

Re: [nodejs] Re: Keeping semantics in your version numbers, i.e. please don't release major version zero

For what it's worth, I see the value in using all three numbers to their fullest potential as the spec describes. Also I explained my usage of node-style semver incorrectly and I apologize. My personal standard is I bump the last digit for both bug fixes and feature additions. Basically any chan

Re: [nodejs] Re: Keeping semantics in your version numbers, i.e. please don't release major version zero

I was going to suggest some version numbers that Node.js could have gone with, but it's not really my place to say something like that. However, Node.js appears to have largely ended it's rapid-breakage phase around 0.4.0 at the latest. There hasn't been any major overhauls, however I've still

Re: [nodejs] Re: Keeping semantics in your version numbers, i.e. please don't release major version zero

By this formula, Node has been 1.0+ since day one and never broken backwards compatibility... Its understandable that young projects hover below 1.0 in order to get a more throughly designed API in place (and maybe fix/remove API kinks that were bad ideas at one point in time)... but some would say

Re: [nodejs] Re: Keeping semantics in your version numbers, i.e. please don't release major version zero

Perhaps this is how it has come to be used, but unfortunately "young and growing" doesn't tell me anything useful about a project once I begin using it. Nor is "architectural change" versus "breaking change" a distinction that an application cares about. Also if you use the minor version number

Re: [nodejs] Re: Keeping semantics in your version numbers, i.e. please don't release major version zero

On Thu, Sep 20, 2012 at 2:27 PM, Austin William Wright < diamondma...@users.sourceforge.net> wrote: > The problem comes in when I or other developers want to *use* those > libraries, and keep them up-to-date. You can't use features like "~1". > You know when you're using a module that's in a 0.x

Re: [nodejs] Re: Keeping semantics in your version numbers, i.e. please don't release major version zero

Library developers don't have any problem sticking with their current scheme, it's not asking anything of them. The problem comes in when I or other developers want to *use* those libraries, and keep them up-to-date. You can't use features like "~1". And this isn't just some nifty feature I'm p

Re: [nodejs] Re: Keeping semantics in your version numbers, i.e. please don't release major version zero

My experience with the node community has been that we love semver, but have a slightly different definition than what's on the website. If an npm module release is a bug-fix then the last digit is incremented. If it's a API breaking change, then the middle digit is incremented and the last digit

[nodejs] Re: Cross Compile nodejs for arm

If you're not set on a particular device yet, you might pick up a used webOS device cheaply.  You're restricted to Node v0.2.3 on phones (Palm Pre 2 or HP Veer) and v0.4.12 on the HP TouchPad, but Node is already tested and optimized. Plus, you can easily write a front end to configure your webs

Re: [nodejs] Re: Keeping semantics in your version numbers, i.e. please don't release major version zero

> I think what semver asks is very reasonable Maybe. I'm just saying the odds of it's requirements being widely adopted are slim to none. I don't think many developers have noticed any problem using 0.x. I shouldn't be so negative though. Feel free to evangelize. I'll shut up. On Thu, Sep 2

[nodejs] Re: Keeping semantics in your version numbers, i.e. please don't release major version zero

If the API has not settled yet, then wouldn't that mean the API is not stable? I think what semver asks is very reasonable: Tell us when you break reverse compatibility. To do this, you can't use 0.x.x. On Thursday, September 20, 2012 12:52:44 AM UTC-7, Mariusz Nowak wrote: > > Austin, version

Re: [nodejs] Re: [ANN] thread.js - a high concurrent ipv4/v6 server of node.js addon

Yes, an explanation of how it is implemented would help a lot. On Thu, Sep 20, 2012 at 6:27 AM, Nuno Job wrote: > Can you provide a better explanation of what the project his, and what the > benchmarks refer to? > > I was curious to understand but didn't really grasp it with the email you > sent

Re: [nodejs] Keeping semantics in your version numbers, i.e. please don't release major version zero

> It's kind of required By whom? The instructions you link to say "Version must be parseable by node-semver". My 0.x releases were parseable by semver. Also those instructions use the example "0.1.2-7 > 0.1.2-7-beta". So forgive me if I didn't know there were rules forbidding 0.x versions in n

[nodejs] Redirect stderr to stdout in child_process.exec

Hi! How can I redirect stderr to stdout while calling an executable via child_process.exec? Best. -- 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 G

Re: [nodejs] use nodejs as streaming server

I would start by reading up on audio encoding formats. This alone is a pretty complex topic. Also, what is you client, what capabilities does it have? If the client is a browser that's very different than say a native mobile client on iOS. As far as the node part, building a simple data proxy i

[nodejs] Re: "eventlocal" and the need for a threadlocal like feature

Look into domains. You can just add a property to process.domain was something that was discussed at NodeConf summer camp. On Thursday, September 20, 2012 9:07:23 AM UTC-5, David Boon wrote: > > Forgive me for reviving this debate about threadlocals. Before anyone > loses their heads, I'm not s

Re: [nodejs] Node 0.8 breaks use of /dev/stdin in child processes

On Thu, Sep 20, 2012 at 4:07 PM, dhruvbird wrote: > Hello, > > So, I'm still trying to understand the implications of this change. Suppose > I spawn "cat" and write to the stdin of the spawned process, then will the > "cat" process not be able to read it? > > var cat = spawn('cat'); > cat.stdin.wr

Re: [nodejs] HA / failover support

I have not seen anything like this currently. Would you also want all of the information from the failed server to fail over as well? On Thu, Sep 20, 2012 at 9:15 AM, Dave Horton wrote: > Are there any features in node relating to high availability or failover > of a server? I would like to be

[nodejs] "eventlocal" and the need for a threadlocal like feature

Forgive me for reviving this debate about threadlocals. Before anyone loses their heads, I'm not suggesting a need for threads or anything like that. However, I've used threadlocal a bit in other languages and and the lack of threadlocal(or something with a less contentious name that has nothi

Re: [nodejs] Node 0.8 breaks use of /dev/stdin in child processes

Hello, So, I'm still trying to understand the implications of this change. Suppose I spawn "cat" and write to the stdin of the spawned process, then will the "cat" process not be able to read it? var cat = spawn('cat'); cat.stdin.write('Foo Bar'); cat.stdout.on('data', function(d) { console.log

Re: [nodejs] Re: [ANN] thread.js - a high concurrent ipv4/v6 server of node.js addon

Can you provide a better explanation of what the project his, and what the benchmarks refer to? I was curious to understand but didn't really grasp it with the email you sent alone. :) Nuno -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-Li

[nodejs] Re: [ANN] thread.js - a high concurrent ipv4/v6 server of node.js addon

Hello everyone, I'm glad to announce a new release of thread.js. I have done two major feature in this release. First, I have implemented a service handler interface that people can write their own protocol and user can install it via npm, and I have done a simple http service handler and run b

[nodejs] HA / failover support

Are there any features in node relating to high availability or failover of a server? I would like to be able to run a cluster of node servers (either physical or virtual) such that if any one dies the others will take over processing, including maintaining the state of running applications on

Re: [nodejs] Re: Keeping semantics in your version numbers, i.e. please don't release major version zero

On Sep 20, 2012 3:52 AM, "Mariusz Nowak" wrote: > > Austin, version v0.x doesn't mean that project is not *stable*, in my point of view everything published on npm should be stable (unstable should just stay on github, or be published under different dedicated minor version, like node does: even n

[nodejs] Re: Windows - USB Install - Modules

Mike - is there any doco you can refer me to on how to install nodejs on the USB drive? On Saturday, August 25, 2012 12:20:25 AM UTC+10, MikeB_2012 wrote: > > I am trying to create a small app nodejs-based app that runs on a USB > drive (that will be inserted in to various Windows OS machines).

[nodejs] use nodejs as streaming server

Hi All I am building a app with push-to-talk (conference call) function. Model of app as below. client A--(voice data)--->server (nodejs)--(voice data)--->client B I have some question. 1. How do get voice data from client? 2. How do send voice data to all connected client? Anyhelp is apprecia

Re: [nodejs] Re: Crockford : Ynode : "I would fork node.js"

On Wed, Sep 19, 2012 at 11:12 PM, rektide wrote: > ps. I'm really a nice guy, hopefully we can meet in person some day and >> we'll laugh about this. > > > Me too. I interpretted some subset of the conversation here as your > intended target of shit-talking dogpile people, which didn't seem fair

Re: [nodejs] Re: Threading, and Dogmatisms.

Paddy Byers gave great insights on the difficuties involved in the "isolates" feature. But there is not a single way to approach multi-threading in node. I'd like to dive a bit into this because I feel that there may have been a bit of a confusion. What the "isolates" feature tried to do is put

[nodejs] Re: Keeping semantics in your version numbers, i.e. please don't release major version zero

Austin, version v0.x doesn't mean that project is not *stable*, in my point of view everything published on npm should be stable (unstable should just stay on github, or be published under different dedicated minor version, like node does: even numbered stable, odd numbered experimental) Versio

Re: [nodejs] Keeping semantics in your version numbers, i.e. please don't release major version zero

It's kind of required if you're releasing a package using npm: https://npmjs.org/doc/json.html On Wednesday, September 19, 2012 11:09:56 PM UTC-7, Mark Hahn wrote: > > > Who else has encountered problems with packages breaking the semantic > versioning scheme > > Not me. I didn't know any of m

[nodejs] [ANN] errno

Issue #4038 made me think that perhaps others might find my little *errno* package useful. It exposes more details on error codes that come from libuv. Particularly useful if your errors need to bubble up to real people that ma