On Jul 28, 2012, at July 28, 201212:22 PM, Tim Caswell
wrote:
> On Sat, Jul 28, 2012 at 2:14 PM, Mikeal Rogers
> wrote:
>>
>> On Jul 28, 2012, at July 28, 201212:05 PM, Tim Caswell
>> wrote:
>>
>>> FWIW, I actually like Bruno's proposal. It
On Jul 28, 2012, at July 28, 201212:05 PM, Tim Caswell
wrote:
> FWIW, I actually like Bruno's proposal. It doesn't cover all the use
> cases, but it makes backpressure enabled pumps really easy.
>
> One use case missing that's easy to add is when consuming a binary
> protocol, I often only wa
After several conversations about this I have identified one thing we lose with
this change.
Because the current implementation makes streams start emitting data right
after creation and could start doing so at any time after nextTick() it's
required that all streams be connected within a singl
readable will get called a lot.
multiple end listeners is rather common.
On Jul 27, 2012, at July 27, 20125:38 AM, Joran Greef wrote:
> Looks good.
>
> How often in practice are multiple on("end") and on("readable") events going
> to be attached?
>
> Would prefer to just have plain vanilla s
On Jun 1, 2012, at June 1, 20121:09 PM, Marco Rogers wrote:
>
>
> On Fri, Jun 1, 2012 at 12:19 PM, Isaac Schlueter wrote:
> First of all, Mikeal Rogers is not a "core guy who doesn't write
> apps". Mikeal Rogers has written several apps with node, and has
>
While I find it flattering to be referred to as a "core guy" and I rarely
correct people when they say it, you should know that I have less patches in to
core than I have fingers.
One of the patches was quite large, but there are many people who spend far
more time on core than I do.
What I sp
On May 31, 2012, at May 31, 20121:21 PM, Paddy Byers wrote:
> Hi,
>
> If a collection is of "indefinite size" then it should not be loaded entirely
> in to memory in order to accomplish computation, it should be streamed. In
> the case of streaming the collection you can iteratively perform th
On May 31, 2012, at May 31, 20121:05 PM, Paddy Byers wrote:
> Hi,
>
> Here's my input, FWIW:
>
> The use cases provided in opposition to this change are very bad
> ideas. In all of the cases presented, what you actually want is
> either a separate thread of execution or an idle listener; *not*
me to fix. I do,
> however have code that is broken under the current implementation that I
> can't fix.
>
> On Tue, May 29, 2012 at 5:05 PM, Mikeal Rogers
> wrote:
>
>
>
>
> On May 29, 2012, at May 29, 20122:42 PM, Marco Rogers wrote:
>
>> Mikeal,
ems as though the responses from Isaac are callus it is because it is
not his job to convince you that this is a real problem, it's your job to
convince him that your solution benefits everyone better and still solves the
problem at hand. That is not happening.
>
> :Marco
>
&g
ing a setImmediate function for 0.9 that matches
> the semantics of the web browser. The intent of setImmediate is to be
> used for cases like this, and it should be pretty easy to implement.
>
> On Tue, May 29, 2012 at 1:31 PM, Mikeal Rogers
> wrote:
> > I have never seen next
>
> Results:
>
> Benching setTimeout
> elapsed: 15593
> Benching nextTick
> elapsed: 2226
>
> So, there is a penalty in switching from nextTick to setTimeout: the call is
> 7 times slower!
>
> On Tuesday, May 29, 2012 10:31:41 PM UTC+2, Mikeal Rogers wrote
I have never seen nextTick recommended for breaking up computationally
expensive tasks, this is what cluster and child_process are for.
Also, setTimeout(cb,0) is very efficient in node and does not suffer the
penalties we are familiar with from the browser. It's actually a better fit for
this u
On May 27, 2012, at May 27, 20121:41 PM, Isaac Schlueter wrote:
> Jorge,
>
> They're not "rare cases". Virtually every use of nextTick is
> specifically designed to allow the attachment of event handlers before
> IO occurs, and every time we use it that way, it leads to sporadic
> failures unde
What is lost here is that you're doing something you shouldn't if you starve IO
this way.
We need a guard, no doubt, but I think it should throw so people can fix this,
not try to let some IO in with 1 second of bad processing in between each.
-Mikeal
On May 27, 2012, at May 27, 201211:38 AM,
ate process.nextTick.
>
> Then no code breaks and we eventually get the right behavior with the right
> name.
>
>
> On Sat, May 26, 2012 at 10:40 PM, Mikeal Rogers
> wrote:
>
>
> On May 26, 2012, at May 26, 20128:16 PM, Jorge wrote:
>>
>> It would m
On May 26, 2012, at May 26, 20128:16 PM, Jorge wrote:
>
> It would mean there's one more thing that can go wrong: the way it's now it's
> ~ impossible to block the event loop (*), the way you're proposing you could.
That's one way to look at it.
Another way would be to say that there is alrea
It's too late to change the name.
Also, the *new* behavior is actually how we've been describing nextTick for
quite some time even though it's never been 100% true.
On May 26, 2012, at May 26, 20125:56 PM, Tim Caswell wrote:
> I would love this, but then the name is wrong. It's more of an afte
On Apr 12, 2012, at April 12, 20122:59 PM, Stéphan Kochen wrote:
> On Thursday 12 April 2012 at 23:37, Mikeal Rogers wrote:
>> The thing is, once there is an UPGRADE, it's not HTTP anymore.
>
> HTTP still specifies that Upgrade must be followed by a response. HTTP on
The thing is, once there is an UPGRADE, it's not HTTP anymore.
For all intents and purposes websockets are NOT HTTP and can't be handled as
such.
Node doesn't offer any core API objects for parsing and encoding to websockets,
it pushes all of that to higher level libraries like socket.io, so th
First of all, THANK YOU!
We've known SSL performance isn't as good as it should for a while but this is
the first solid benchmark I've seen.
Could we get this added to the benchmarks in core?
https://github.com/joyent/node/tree/master/benchmark
-Mikeal
On Feb 28, 2012, at February 28, 20123:2
We've talked about this before and it's not really possible.
For one thing, the OS lies, it'll hold a buffer around of data is has/hasn't
actually sent out yet, on OS X it's half a meg.
What pipe does now is ensures that both ends, the reader and the stream being
written to, are both going at t
we can cross that bridge when we come to it.
IMO, patches against master should be made against master without regard for
future plans for re-writes. It's the job of the re-writer to make all the tests
pass so if your change goes in with a test it'll still work after the re-write.
-Mikeal
On F
I am all for this going in but I'm wondering why we have a thread on the list
about it when we have a pretty good GitHub issue already?
Was there something that we need to discuss that's not in
ticket/upcoming-pull-request?
On Feb 12, 2012, at February 12, 20127:06 PM, Charlie Robbins wrote:
>
Again, this is the *exact* conversation we had about the Host header, down to
the "but i need to remove it for testing". Turned out you really do, because
people's shitty HTTP implementations won't give you the right headers and
you'll need to test that you have sane defaults.
If we can't learn
On Feb 8, 2012, at February 8, 201210:22 PM, Ben Noordhuis wrote:
> On Thu, Feb 9, 2012 at 03:58, Marco Rogers wrote:
>> I also think there is a bit of a contradiction between "low level" and
>> "hiding implementation". IMO low level apis should expose as much as of the
>> guts as possible (in a
On Feb 8, 2012, at February 8, 201210:22 PM, Ben Noordhuis wrote:
> On Thu, Feb 9, 2012 at 03:58, Marco Rogers wrote:
>> I also think there is a bit of a contradiction between "low level" and
>> "hiding implementation". IMO low level apis should expose as much as of the
>> guts as possible (in a
On Feb 8, 2012, at February 8, 20129:58 PM, Marco Rogers wrote:
> I also think there is a bit of a contradiction between "low level" and
> "hiding implementation". IMO low level apis should expose as much as of the
> guts as possible (in a clean and consistent way) to provide maximum
> flexibi
// go on with regular stuff here
>> });
>>
>> IMHO we should at least supply something reasonable to make that
>> happen. In Connect I'm using a "header" event, it's not as "clean" as
>> something like rack but like I've said before I
he practice to date seems to lead towards writing things initially very
restrictive initially and then people like TJ and Marco fighting to expose them.
On Feb 8, 2012, at February 8, 20124:18 PM, tjholowaychuk wrote:
> +1 been saying this for years
>
> On Feb 8, 1:04 pm, Mikeal Rogers
All the streams in core are in some half state between declarative and
composable.
http.ServerResponse is probably the biggest/worst example where:
http.writeHead(status, headers)
can, in some cases, entirely opt out of the composable headers set:
http.setHeader(name, value)
in particular, th
This is the exact same conversation we had over the host header.
Unfortunately the host header went in at first without a way to disable it. Now
there is, we should replicate that.
-Mikeal
On Feb 8, 2012, at February 8, 20121:48 PM, Marco Rogers wrote:
> +1 to this going in. Node boasts a lot
I mostly deal with signing requests, not signing responses.
Just to be clear, we are only adding this to ServerResponse right?
Nuno, in what cases are you signing responses?
-Mikeal
On Feb 8, 2012, at February 8, 20129:31 AM, Nuno Job wrote:
> This is going to make http-signing unpredictable a
This should go in.
I mean, I care about this kind of stuff, I don't like breaking the spec, but I
don't think any of my server code uses a Date header at the moment :)
On Feb 7, 2012, at February 7, 20124:30 PM, Isaac Schlueter wrote:
> I don't know... I kind of see this as somewhat similar to
34 matches
Mail list logo
