What about an API in which a new pseudo stream was created, so, `writev`
becomes something of a mode on streams, such that you could do
something like:
stream.bulk(function(bulkStream){
bulkStream.write(buf, enc);
bulkStream.write(buf, enc);
bulkStream.write(buf, enc);
bulkStream.end(buf, enc)
So what's your remaining issue with cork/uncork exactly? Just that it's
ugly?
:Marco
On Wednesday, April 24, 2013 5:48:59 PM UTC-7, Isaac Schlueter wrote:
>
> > Are you saying that whatever we choose, users will get the benefits of
> this for free in the 80% case?
>
> Yes, that is what I'm say
> Are you saying that whatever we choose, users will get the benefits of this
> for free in the 80% case?
Yes, that is what I'm saying.
> Is this type of operation always synchronous? If s.bulk(function() {})
> suggests that you're ready to write everything within the execution of that
> func
I think you're answering my primary concern. Are you saying that whatever
we choose, users will get the benefits of this for free in the 80% case? If
that's true, then I think the unusual case should have the most flexible
interface. That feels like cork/uncork to me. But take my opinion with a
gra
> Of course it'd be no use where there's a need to different encodings
> for some of the chunks, but how common a requirement is that?
It's as common a requirement as `res.write('some string that is
probably utf8')`. Requiring all chunks to be the same encoding is not
reasonable for the use case
+1 for cork/uncork, that's it.
Cheers,
Fedor.
On Wed, Apr 24, 2013 at 5:05 PM, Mike Pilsbury wrote:
> Is this signature not worth considering?
> stream.writev([chunks,...], encoding, callback)
>
> It's an easier API to use. No need to create an object for each chunk.
>
> Of course it'd be n
Is this signature not worth considering?
stream.writev([chunks,...], encoding, callback)
It's an easier API to use. No need to create an object for each chunk.
Of course it'd be no use where there's a need to different encodings for
some of the chunks, but how common a requirement is that?
I've been trying to follow this thread, but there's a lot here. I apologize
in advance if I'm retreading anything that's already been said.
I have a simple question first. Are you considering having both the
flexible cork/uncork api and also putting a nice api on top of it with C/D
option? That
On Wed, Apr 24, 2013 at 12:29 PM, Isaac Schlueter wrote:
> Anyone unfamiliar with TCP_CORK should read this:
> http://baus.net/on-tcp_cork
>
Holy comment spam!
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You
Matt,
Yeah, I'm kind of in agreement here. TCP_CORK is a venerable old TCP-ism.
Functionally, though a top-level writev([{chunk,encoding}],cb) or
writev([chunks],[encodings],cb) *seems* a bit simpler, it's actually
not saving much complexity, compared with what it adds to the Writable
user. (No
On Wed, Apr 24, 2013 at 11:09 AM, greelgorke wrote:
> stream.end should uncork and +1 (or see my prev post)
>
> Am Mittwoch, 24. April 2013 15:18:08 UTC+2 schrieb Matt Sergeant:
>>
>> I'm gonna go against the crowd and ask for B:cork/uncork here. It's far
>> easier for when you don't have a bunch
stream.end should uncork and +1 (or see my prev post)
Am Mittwoch, 24. April 2013 15:18:08 UTC+2 schrieb Matt Sergeant:
>
> I'm gonna go against the crowd and ask for B:cork/uncork here. It's far
> easier for when you don't have a bunch of pre-composed buffer objects, and
> would fit into someth
I'm gonna go against the crowd and ask for B:cork/uncork here. It's far
easier for when you don't have a bunch of pre-composed buffer objects, and
would fit into something streaming lines to the output a lot better. Yes
you can fuck up, but there's a million ways the programmer can fuck up with
nod
> +1 C / D, D would be less awkward as far as building up the things
> you're passing to .writev() goes, but the arrays are alright. Less
> fancy stuff in core++
Part of my complaint about parallel arrays is that we'd probably end
up having to re-match them in many cases anyway. An array of
{chun
I like D) stream.writev([ {chunk:buf, encoding: blerg}, ...], callback)
The leveldb driver has a very similar batch api (
https://github.com/rvagg/node-levelup#batch )
the leveldb driver also has a large thread about possible better APIs (
https://github.com/rvagg/node-levelup/issues/45 ) from wh
+1 C / D, D would be less awkward as far as building up the things
you're passing to .writev() goes, but the arrays are alright. Less
fancy stuff in core++
On Apr 22, 5:01 pm, Isaac Schlueter wrote:
> There's a syscall called `writev` that lets you write an array (ie,
> "Vector") of buffers of da
16 matches
Mail list logo
