[nodejs] Re: Heartbleed bug - openssl leaking private keys :-((

Many distributions link OpenSSL as a shared library, including RedHat, CentOS, Fedora, Debian, Ubuntu, Gentoo, and others. These are most certainly affected. Please check your running server directly to see if you're affected. http://filippo.io/Heartbleed/ seems to work well. I would *not* sug

Re: [nodejs] Re: Build nodejs with an alternative build system?

On Wednesday, March 5, 2014 10:51:05 AM UTC-7, Ryan Dahl wrote: > > On Wed, Mar 5, 2014 at 9:42 AM, Kevin Ingwersen > > > wrote: > >> That I noticed. But isnt it possible to use v8 with autotools or similar >> - or does it really completely rely on gyp? >> I myself can’t really make myself a bi

[nodejs] Re: Build nodejs with an alternative build system?

About six months ago I ported the build system to a single Makefile, less than 200 lines. The system became immensely more flexible and portable, but it became hard to keep up with the build system changes, and it's nearly impossible to compile V8 without python (I was linking against a shared

[nodejs] Re: we need a new mongodb driver for node

Can you please link to your project? Possibly we can add this behavior to the existing node-mongodb-native driver? It has to support database failovers and connection failures already, so it shouldn't be hard to implement a new connect() function around this functionality. I really like

Re: [nodejs] Re: Good way to store passwords server-side for node apps

On Saturday, December 28, 2013 3:19:43 PM UTC-7, Alex Kocharin wrote: > > > 29.12.2013, 02:07, "Austin William Wright" < > diamon...@users.sourceforge.net >: > > I suggest JSON because it's easy, and the use-case here is only likely to > need a han

Re: [nodejs] Re: Good way to store passwords server-side for node apps

t; > > 28.12.2013, 03:33, "Austin William Wright" < > diamon...@users.sourceforge.net >: > > Just use a configuration file, it can be as easy as require()ing a JSON > file: > > var config = require('./config.json'); > var db = database.connect(

[nodejs] Re: Good way to store passwords server-side for node apps

Just use a configuration file, it can be as easy as require()ing a JSON file: var config = require('./config.json'); var db = database.connect(config.host, config.user, config.password); Then add an config.example.json to your repo, and add config.json to your .gitignore. You may also wish to

[nodejs] Re: application/vnd.api+json - IANA specification for the json api

That's not just any JSON document, but one with a particular well-defined structure to expose hyperlinks. It appears to be Yet Another Hypermedia JSON Format. On Friday, October 25, 2013 6:44:58 AM UTC-7, Gagle wrote: > > This may be of your interest, IANA approved the mime type of a json api: >

Re: [nodejs] Can nodejs create a crypto key + certificate for me?

What are you actually trying to do? Implementing security isn't something to take lightly... Even if you think you're not protecting anything of great importance, your users often are. For instance, many users will (despite appeals to common sense) use the same password that they do for their b

[nodejs] Re: When is it safe to catch errors?

To the best that I can discern, Domains is referring to attaching "error" handlers to the process or a domain (which handle *un*caught errors), and the *solution* is `catch`ing and appropriately handling the Error. If a thrown Error has been caught by `process`, that means no user code couldn't

[nodejs] Re: Express - REST doc, but how ?

I don't think this should really be necessary: The whole point of REST is that it's self-documenting, that any old user agent (like a web browser, but also robots) should be able to pull up the endpoint and start interacting with it.. This is typically done with HTML forms and hyperlinks (and a

[nodejs] Re: why are my replies being deleted?

Yes! For the Google Groups Web interface, particularly the new "forum" one? I've been getting that. Usually it's immediate. Once or twice it may have been after a few hours. Not on this list, though. On Friday, July 26, 2013 11:00:05 AM UTC-7, mgutz wrote: > > Just wondering if anybody else's m

[nodejs] Re: Private variables and setTimeout issue.

Yeah, I should have provided some vocabulary (so you can Google or whatever). It's a function, placed in parenthesis, and then immediately invoked (by the second pair of parenthesis). It executes a block of code inside the scope of a function. We've tended to call it an immediately-invoked fun

[nodejs] Re: Private variables and setTimeout issue.

Not a bug, just wrap the scope that you want to use in a function call: for (var i=0; i < array.length; i++) (function(i){ var item = array[i]; setTimeout(function() { console.log(item); }, 1000*i); })(i); Or use Array's forEach method which does this more compactly: array.fo

Re: [nodejs] Build Nodejs as dynamic library

There's no major roadblock preventing one from compiling a shared object; I just successfully built `node.so` from master branch, it just involves adding a few compile flags here and there. I haven't tried linking against it or otherwise using it. How useful it actually is, in its current state

[nodejs] Re: File hash issue of chunked file uploading with nodejs

I'd just like to point out the existence of the Content-Range header. It's not thoroughly described for use in making uploads, but since it's an entity-header, you can use it in requests/uploads as well as responses, and there's several examples

Re: [nodejs] Re: Fun little HTTP "bug"

On Friday, June 21, 2013 7:21:14 AM UTC-7, Matt Sergeant wrote: > > On Fri, Jun 21, 2013 at 4:58 AM, Austin William Wright < > diamon...@users.sourceforge.net > wrote: > >> I believe this is correct behavior. Once $Content-Length amount of bytes >> have been sent,

[nodejs] Re: Fun little HTTP "bug"

I believe this is correct behavior. Once $Content-Length amount of bytes have been sent, the response is finished, and the next item in a connection should be the "HTTP/1.1" header to mark a new response. The error code basically means "Unexpected start of a response". On Thursday, June 20, 201

Re: [nodejs] Re: The Magnode content management system (and "Why Node.js?!")

Press experience and I love that your >> theme is twentyonetwelve. I've been thinking about a NodeJS blog >> implementation and while I fought agains the "why Node?" question for a >> while I finally decided it was worth exploring. You've done a lot of the >

[nodejs] The Magnode content management system (and "Why Node.js?!")

Every so often (maybe twice a week in IRC) someone asks about a blog, e-commerce, or content management system for Node.js. I feel compelled to ask "Why Node.js", because it seems like one of those "I want to do it because I can" rationales. Most people have that exact reason, and not much else

Re: [nodejs] Re: please include the full MIT license in your modules or they have none

On Wednesday, March 27, 2013 11:49:00 AM UTC-7, Mark Hahn wrote: > > > But may I ask, why is your company listening to these lawyers. > > Who should we listen to then? > > > I'm not aware of any case law where someone got in trouble for > utilizing code published publicly by the author for the

Re: [nodejs] Re: please include the full MIT license in your modules or they have none

they don't apply to the population in general. The statute itself was passed in the Berne Convention Implementation Act of 1988. On Wednesday, March 27, 2013 10:52:07 AM UTC-7, psema4 wrote: > > On Wed, Mar 27, 2013 at 1:43 PM, Austin William Wright > > wrote: > > If a work

Re: [nodejs] Re: please include the full MIT license in your modules or they have none

t;> >> >> On Wed, Mar 27, 2013 at 10:00 AM, Dick Hardt >> > >> wrote: >> > Actually, that is not true. There are several MIT licenses, so unless >> the >> > actual license text is included, it is ambiguous what the license is: >> >

Re: [nodejs] Re: please include the full MIT license in your modules or they have none

On Wednesday, March 27, 2013 10:14:00 AM UTC-7, Isaac Schlueter wrote: > > I had no idea there were so many experienced IP lawyers on this > mailing list! How lucky we are! It's amazing that you all found time > to learn JavaScript, what with going to law school, passing the bar, > and then b

Re: [nodejs] Re: please include the full MIT license in your modules or they have none

or alternatively stating the full license in the README.md > > -- Dick > > On Mar 27, 2013, at 9:55 AM, Austin William Wright < > diamon...@users.sourceforge.net > wrote: > > A license is something that is granted by the author at distribution-time, > it need not be

[nodejs] Re: please include the full MIT license in your modules or they have none

A license is something that is granted by the author at distribution-time, it need not be included in the package contents. If an author wholly owns the copyright on their work, they can offer the program to you under any license they want, regardless of what the file inside the repository or p

[nodejs] Re: json data filters defined in json

tell wrote: > > Thanks for the reply! > I hadn't thought of using jsonschema that way (i use it and valid-schema > everyday). I'm really looking for something specific to logical quieres > however. > > On Friday, March 1, 2013 3:03:29 AM UTC-8, Austin William Wright wrote:

[nodejs] Re: json data filters defined in json

It's called JSON Schema, see . Try . The schema for your instance would be something like: { type: "object" , properties: { "num": {type:"integer", minimum:0, maximum:2000, exclusiveMaximum:true} , "name": {value:"foobar"} }

[nodejs] Re: Is there a lib to parse IRI(rfc3987)?

My 'rdf' module contains an IRI parser, rdf.IRI. It uses standard URI/IRI vocabulary terms. I haven't gotten to checking that it's fully compliant with the RFC in detecting errors, or that offers all the functionality you want, can you offer some examples?

[nodejs] Re: which are the big applications running on node.js

Preferably projects with published source code. "Big company X uses Node.js" is nice, but doesn't demonstrate very much. On Thursday, February 14, 2013 9:24:44 AM UTC-7, dmorilha wrote: > > I am interesting in hearing which are the big and complex projects running > on node you guys heard about.

Re: [nodejs] a pakage that exports few modules

numbers are meaningless, and we should move to Git commit ids (or "commits in ancestry" if you really like growing numbers). On Thursday, January 24, 2013 2:28:24 PM UTC-7, Mikeal Rogers wrote: > > > On Jan 24, 2013, at January 24, 20131:03 PM, Austin William Wright < >

Re: [nodejs] a pakage that exports few modules

g the effort to reason like I am. Taking the time to reason your design isn't the first thing people tend to do, it's non-obvious. Though I wouldn't say I'm the only one here, I'm jumping to the defense of at least two others here in favor of some fractio

Re: [nodejs] a pakage that exports few modules

On Thursday, January 24, 2013 12:57:13 PM UTC-7, Isaac Schlueter wrote: > > You're about 2 years too late, Austin. > > We only break reverse-compatibility when absolutely necessary, and > never for modules that are marked with the "Stable" stability level or > higher. > There are some act

Re: [nodejs] a pakage that exports few modules

On Wednesday, January 23, 2013 9:04:52 PM UTC-7, Isaac Schlueter wrote: > > On Wed, Jan 23, 2013 at 7:30 PM, Austin William Wright > > wrote: > > ... > > Look, here's the bottom: The module system is locked. We're not > interested in changing it. The

Re: [nodejs] a pakage that exports few modules

right further down. The only reason we're in such a good position now is because of node_modules - a replacement of commonly used behavior with NODE_PATH and require.paths. > On Wed, Jan 23, 2013 at 6:18 AM, Austin William Wright > > wrote: > >> "Objectively correc

Re: [nodejs] a pakage that exports few modules

On Wednesday, January 23, 2013 1:13:47 AM UTC-7, Isaac Schlueter wrote: > > On Tue, Jan 22, 2013 at 7:00 PM, Austin William Wright > > wrote: > > On the contrary, what sort of project could Node.js be if everyone > actually > > cared about doing things

Re: [nodejs] a pakage that exports few modules

On Monday, January 21, 2013 7:46:01 PM UTC-7, Isaac Schlueter wrote: > Who's a wall? You can either put your files in the root of your > package, or you can put "lib/" or whatever in your require() function > calls. You're saying that you want to add complexity to Node that *no > one else wan

Re: [nodejs] a pakage that exports few modules

On Friday, January 18, 2013 9:42:10 PM UTC-7, Isaac Schlueter wrote: > > On Fri, Jan 18, 2013 at 7:34 PM, Jake Verbaten > > > wrote: > > You could just move your files to the root of your folder. If there are > too > > many files then don't have so many files. > > This. Exactly this. > Y

[nodejs] Re: Running javascript code "safely"

I'd call this a bug, none of the context is supposed to be shared, including Function and Object. On Friday, January 18, 2013 12:15:38 PM UTC-7, Bradley Meck wrote: > > Austin: won't go into great detail, but heres a fun little example: > > ```javascript > function exploit() { > console.log.con

[nodejs] Re: Running javascript code "safely"

Why won't require('vm') with strict mode work? Let's assume that no while(1) loops will be run. And of course, you cannot statically determine every script that will end up running forever, never mind which functions will take an unnecessary amount of resources. On Wednesday, January 16, 2013 2

[nodejs] Re: Checking node_modules into git

Using git submodules is my preferred style when writing applications. That way you point to an exact source code tree, all the while you keep their respective commit histories. I have a Git program (in Node.js) that manages the submodules for Node.js dependencies,

[nodejs] Re: On "Reserving" Package Names

On Wednesday, December 19, 2012 2:35:10 AM UTC-7, Floby wrote: > > Well, the NPM repository is in fact Isaac's repository. And Isaac says > that he doesn't want empty packages in his repository. > I don't see how it can be more complex than that. If one wants to publish > dozens of empty module

Re: [nodejs] preferred license for node modules?

It is a clear-cut thing: "Linking" in the context of copyright means to embed another program (compiled or otherwise) inside your program *and*distribute it. The GPL does not decide when it gets to be applicable, all it gets to do is decide when to grant permission to distribute. If you're not

Re: [nodejs] preferred license for node modules?

The CLA is already unnecessary. No court has ruled otherwise when it comes to derivative works. On Saturday, December 15, 2012 12:51:40 PM UTC-7, Ben Noordhuis wrote: > > On Sat, Dec 15, 2012 at 6:48 PM, Isaac Schlueter > > wrote: > > Apache2 has much more thorough coverage of patents and other

[nodejs] Re: On "Reserving" Package Names

On Friday, December 14, 2012 5:10:23 PM UTC-7, Isaac Schlueter wrote: > TL;DR - Package squatting is not allowed. If you sit on a package > name and don't publish code, it'll be deleted without warning. > ... > It is hard to really comprehend *just how many* possible package names > there are.

Re: [nodejs] preferred license for node modules?

On Saturday, December 15, 2012 12:36:16 AM UTC-7, Jonathan Dickinson wrote: > On Saturday, 15 December 2012 06:38:14 UTC+2, Raynos wrote: > >> I have zero dependencies on GPL modules for that reason and won't use any >> npm modules that are under the GPL licence. >> >> > This brings up a good poi

Re: [nodejs] preferred license for node modules?

On Friday, December 14, 2012 9:38:14 PM UTC-7, Raynos wrote: > From my understanding is that if I have a dependency on a GPL module no > matter how deep in my dependency tree (my larger apps have over a 100 > dependencies) my entire app is GPL. > Where in the world do you get this impression? Th

[nodejs] Re: i want to encrypt passwords before sending to database using md5

No. MD5 is broken. If someone insists on using MD5, trust them *less* because they may be trying to create an illusion of security where in fact none exists. Hash functions are not, by themselves, suitable for creating encryption keys (including hashed passwords for that matter) where the secu

[nodejs] Re: Github Organization for projects without maintainers

So then why not fork the project? The great thing about open source software in Git is you don't need permission. As for the npm registry, I don't know how else you'd do that, people have to own their little corner of the namespace. The problem with npm (one of many) is that it uses a single, g

[nodejs] Re: Poll for v0.10 feature: Crypto default to 'binary' strings vs defaulting to buffers

(a) Yes, *please.* Changes in the behavior of binary strings, and the usage of binary strings alone, has hurt me in the past. And even if Node.js *was* version 1.0.0, that's still no excuse to not improve the API. It should go without saying, remember to document and announce the behavior chan

[nodejs] Re: streams or emitter

On Wednesday, September 26, 2012 11:22:45 PM UTC-7, Julian Gruber wrote: > > Or is there another way of dealing with 'two-way-streams'. This should be > a common pattern in realtime applications! > I believe in computer science this is called a double-ended queue

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

I was going to shut up and I didn't. I will try harder now. > > > On Thu, Sep 20, 2012 at 5:38 PM, Austin William Wright < > diamon...@users.sourceforge.net > wrote: > >> I never said you need to trust the library developer, but that's no >> excuse f

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

elopers. 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 version numbers. I > can't imagine making any of my decisions based on version numbers. > > On Thu,

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

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,

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

eally liked the outcome of this change. On Thursday, September 20, 2012 12:54:40 PM UTC-7, Tim Caswell wrote: > > 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

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

lieve. Certainly it'd help me. On Thursday, September 20, 2012 12:16:07 PM UTC-7, Rick Waldron wrote: > > On Thu, Sep 20, 2012 at 3:10 PM, Austin William Wright < > diamon...@users.sourceforge.net > wrote: > >> The API *does not need to be *what you definitely want.

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 2:59 PM, Austin William Wright < > diamon...@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 >

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

a leading 0.? This inconsistency is confusing and unnecessary. On Thursday, September 20, 2012 11:30:44 AM UTC-7, Scott González wrote: > > On Thu, Sep 20, 2012 at 2:27 PM, Austin William Wright < > diamon...@users.sourceforge.net > wrote: > >> The problem comes in when I or o

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

ed > > 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 20, 2012 at 11:10 AM

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

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 20, 2012 at 11:10 AM, Austin William Wright < > diamon...@users.sourceforge.ne

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

experimental) > > Version v0.x just means that's it's API has not settled yet and it can > change breaking backwards compatibility. It's exactly the reason why > Node.js is not yet 1.x, and it's up to semver rules. > > On Thursday, September 20, 2012 3:43:

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

ot me. I didn't know any of my packages were using this scheme. Is it > widely adopted? > > > On Wed, Sep 19, 2012 at 6:43 PM, Austin William Wright < > diamon...@users.sourceforge.net > wrote: > >> I've noticed that quite a lot of Node.js packages are

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

I've noticed that quite a lot of Node.js packages are tagging version number zero for all their releases: 0.4.0, 0.9.9, 0.0.1, 0.27.4, etc (to pick from packages that I use). It's as if people think that if the program is not fully feature-complete, they shouldn't release version 1.0.0. You nee

[nodejs] Re: Counting on Object Insertion Order

ECMAScript currently does not define an order in which keys will be read, however it allows implementations to do so, if they keep the order consistent. V8 guarantees that non-numeric keys (due to Array's behavior) will be read in insertion order, and future drafts of ECMAScript may guarantee s

[nodejs] Re: bcrypt or md5 ?

On Monday, July 30, 2012 12:05:32 PM UTC-7, Yogesh Agrawal wrote: > > Which is more preferable to save password in DB, bcrypt or md5 ? > > I found https://github.com/ncb000gt/node.bcrypt.js/ lib, which is a addon > to node.js to encrypt the passwords. > > Also I found that md5 based hashing is n

[nodejs] Re: bcrypt or md5 ?

Don't use MD5 for anything. Ever. If someone is asking you to use md5, trust it *less*, because they're likely trying to give you the impression of security, when in fact none exists. MD5 produces collisions, it's cheap to produce collisions, and it's vulnerable to length-extension attacks (lik