On Mon, Jul 23, 2012 at 2:09 PM, Isaac Schlueter <i...@izs.me> wrote:
> I'd like to move http (and dgram, dns, and the like) out of core one
> day. But, that day will not come soon. We have a lot of work to do.
>
> As Dominic mentioned, http was very important to our success up till
> now. Node is for writing websites and other network services. The
> original vision was to have node-core contain core network protocols
> and the necessary things to have a good module system.
>
> As we've explored this space, I think it's become more and more clear
> that http is not really the core network protocol. TCP is, and we
> should eventually move all the HTTP machinery up and eventually out.
> npm needs to be eventually split up into a few parts: the core
> 'install modules' bits should go into node-core as a first-class part
> of the module system, and the 'publish modules' bit should be
> installed by default as it is today.
If anyone is itching to pull http out of core, my luvit project (which
is node ported to lua) is still somewhat API unstable. Meaning we can
make breaking API changes without angering the masses. I've been
wanting to pull http out of core for the same reasons Isaac mentions.
I'd be willing to use luvit as a test-bed for this experiment. I'm
not sure how much of the experience would translate to node.js
(javascript has primarily been the language of the web, and http is
the protocol used most in browsers)
> Then we should do away with the package.json file for everything
> except publishing and stating dependencies, and make the development
> process more automatic; if you require('http') it should Just Work by
> fetching the http module that you need to use. (How to pick the right
> one if there are several updates? That is a bigass TBD. It's a lot
> of work.)
>
> For deployment, we should take shrinkwrap or "check in your deps" a
> step further, and have a way to create a static standalone bundle that
> can be deterministically unpacked and installed on a remote machine.
Yes, I really want this for both node.js and luvit. This is
especially important as we move into front-end apps using things like
chromium embedded frame, egl/opengl, cocoa, etc.. In the end, you
just want an easy way to distribute your application as a single
bundle.
> I can't say enough: This is all very long-term fantasizing. It's a
> ton of work to get there, and there are plenty of other issues to deal
> with sooner. When we get closer, we might find that some of it
> doesn't make sense.
I should mention I'm not trying to divert effort away from node, but
rather offering a place to experiment. I still work on node and node
modules full time every day. I started the luvit project for several
reasons, but one of them was to give me a place to experiment with
things not possible in node itself (like language supported
coroutines, or arbitrary core API changes)
>
>
> On Sun, Jul 22, 2012 at 5:44 AM, Oleg Efimov (Sannis)
> <efimo...@gmail.com> wrote:
>> HTTP is in core because it is frequently used.
>>
>> There is aslo some words about core vs userland in wiki:
>> https://github.com/joyent/node/wiki/node-core-vs-userland
>>
>> I think you should not worry about speed in this context: build-in modules
>> mostly affects node executable size and start-up RSS, not "speed".
>>
>> воскресенье, 22 июля 2012 г., 4:27:34 UTC+4 пользователь beachdog написал:
>>>
>>> I'm coming up to speed on the node core, trying to learn things at a very
>>> detailed level because I need something for my application area that will
>>> probably be a lot like node -- either using node itself or developing a
>>> similar v8-based framework for my purposes. And I am interested in the
>>> decision process of which objects to include in the node core vs leaving out
>>> for add-ons. As I see it, the general desire would probably be to keep the
>>> core minimal and only include objects that either
>>>
>>> provide functions the core itself needs in order to operate (e.g., module,
>>> fs, path etc), OR
>>> provide the single implementation that it is important everyone use in
>>> their modules to achieve interoperability(e.g., EventEmitter), OR
>>> provide significant performance improvements by being in the core
>>>
>>> With that in mind, I see a lot of objects that are in the core which
>>> (maybe) don't meet that criteria. As an example, I want to build a platform
>>> where http is only one of many IP protocols and not the 'first among equals'
>>> that it seems to be in node -- so for me, its not clear why http is in the
>>> core. Or crypto, or others. Since I'm still coming up to speed, I'm
>>> wondering if I am missing something. If not, I would be interested to know
>>> the perspective from node devs -- if they were to start over with a blank
>>> sheet of paper so to speak, what would be in core and what would be provided
>>> outside of core?
