bring useful node modules into this organization for better maintenance

[jonathanong]

ex. @mikeal could move request here. that's the only module i can think of right now.

[rvagg]

Not a terrible idea, we could extend it to bring in readable-stream, string_decoder, core-util-is and other extracted-from-core libraries and have them managed primarily in their own repos and have core pull them in from there. I send people to core when they bring up issues for readable-stream but there's no good reason why there shouldn't be a group of devs who are primarily concerned about streams dedicated to managing that as a totally separate project from core as long as core's needs are served by it.

[Fishrock123]

👍

[dougwilson]

I ❤ "extract-from-core modules" (aka dual-life modules).

[mikeal]

what about being in this org directly correlates to "better maintenance?"

request actually has a pretty active community on the existing repo, in fact I just added another contributor today. being an org has some other strange side effects, like the fact that org owners end up being committers in every repo, which blurs the lines a bit of who should be committing to what.

conversely, @hueniverse has been taking over modules that aren't maintained and pulling them in to the hapi org where he has a well defined contribution model. that could work here, if we were to define such a contribution model, but request is actually a fairly poor example since it finally has a well defined governance model and a healthy and growing set of contributors.

[Fishrock123]

conversely, Eran Hammer has been taking over modules that aren't maintained and pulling them in to the hapi org where he has a well defined contribution model.

This general sort of model has been working fairly well for us in the expressjs / pillarjs / jshttp orgs.

[Fishrock123]

I would support the "extract-from-core modules" (aka dual-life modules). living here. (Stuff like readable-stream etc.)

[mikeal]

readable-stream is a great example. what about modules that basically replace core functionality like https://github.com/rvagg/nan ?

[Fishrock123]

My vote is for readable-stream because it basically is core functionality.

Is nan core functionality?
Could our native abstractions be replaced with nan? (I'm a js guy so I have no clue lol)

[mikeal]

nan should be core functionality but isn't :) I wonder what @rvagg things.

[Qard]

As a nan user myself, I wish something like it was actually in core. It'd
be nice to have something a little more polished. There was some efforts
for a proper C API, but it doesn't seem to have gone anywhere.
On Oct 11, 2014 2:29 PM, "Mikeal Rogers" [email protected] wrote:

nan should be core functionality but isn't :) I wonder what @rvagg
https://github.com/rvagg things.

—
Reply to this email directly or view it on GitHub
#4 (comment)
.

[Fishrock123]

There was some efforts
for a proper C API, but it doesn't seem to have gone anywhere.

I was interested in that. I'm not going to bother learning C++ for bindings but I would learn C.

However I'm really in the camp that is all like "rust bindings yo". ;)

[rvagg]

There was some efforts for a proper C API, but it doesn't seem to have gone anywhere.

Not quite true, see https://github.com/tjfontaine/node-addon-layer for a usable solution here, it just hasn't got the traction that NAN has so hasn't matured as rapidly. They are separate approaches though, NAN is about compatibility and making sure you don't have to discard your old code or your knowledge of V8 internals. My ideal however is to move towards something a little more runtime-agnostic so we're not as closely pinned to V8, but that's another story!

I'd be open to moving it here if there was a real benefit to that; keeping in mind that I've effectively given away chunks of ownership to other contributors so it'd have to be a collective decision.

I'd like to wait for some dust to settle though!

[Qard]

Yep, I'm aware of it. nan seemed more popular and better maintained last
time I wrote a native module though.

I agree a more runtime-agnostic approach would be great, as would having it
in core node.
On Oct 11, 2014 8:04 PM, "Rod Vagg" [email protected] wrote:

There was some efforts for a proper C API, but it doesn't seem to have
gone anywhere.

Not quite true, see https://github.com/tjfontaine/node-addon-layer for a
usable solution here, it just hasn't got the traction that NAN has so
hasn't matured as rapidly. They are separate approaches though, NAN is
about compatibility and making sure you don't have to discard your old code
or your knowledge of V8 internals. My ideal however is to move towards
something a little more runtime-agnostic so we're not as closely pinned to
V8, but that's another story!

I'd be open to moving it here if there was a real benefit to that; keeping
in mind that I've effectively given away chunks of ownership to other
contributors so it'd have to be a collective decision.

I'd like to wait for some dust to settle though!

—
Reply to this email directly or view it on GitHub
#4 (comment)
.

[Fishrock123]

What about having these things be "official" - but eventually not in core itself? Sort of what http://r.va.gg/2014/06/why-i-dont-use-nodes-core-stream-module.html talks about.

Though in that case we'd have to have a spec so things stay consistent and sane maybe. Probably a bad idea. maybe idk.

[kkoopa]

I guess NAN got more traction for two reasons: Critical mass and the degree of how much the syntax changed. We created critical mass by submitting finished PRs to every project we found, I've done about 20, @rvagg has probably done about as many. This was both to test the code and approach, as well as to build critical mass.

Then comes that the syntax did not change terribly much, existing code can still be almost fully automatically ported through simple regexes. This was intentional to make it possible to port all those projects and get the code accepted.

It may not be ideal, but standard engineering doctrine says 80 % delivered now is better than 100 % never delivered. NAN will eventually become obsolete, as people want to take advantage of domains and multiple isolates and all the new things that have been introduced in v8, but that will also entail said addons dropping 0.10 support, which is probably a couple years in the future. Because v8 is a moving target, this problem cannot be resolved without completely abstracting away v8, which probably will not work too well and still will not guarantee never breaking again, as something unforeseen will come up at some point.

That being said, I agree with @rvagg, moving it here is possible, and probably beneficial in that the vast majority of native addons now use NAN. It has become a de facto standard and it will be (already is) annoying for addon writers to report bugs in Node when they first have to translate their failing code to raw Node so as not to be dismissed with the no third-party addons excuse. However, this brings us into what @Fishrock123 wrote, the often forgotten second party remains a possibility. For example, six is a semi-official compatibility package for python 2 and 3. Then there are plans of doing NAN for libuv too, which will probably be a separate project, and so on. Maybe this is indeed the best option?

[ronkorving]

@kkoopa And I'm still greatful for those contributions to this day ;) (https://github.com/JustinTulloss/zeromq.node) It made a big difference to the project and its Node 0.11 and backwards support.

[martinies]

Great idea! We (like many others) struggled with many modules not getting a support. Once we made a small fix but couldn't even reach to the developer to update the package on npm..