API

[jonathanong]

right now it's push(res, [path], [options], [priority]) which has too much arity. i'm thinking about making it fluent, something like:

spdy(res).push(path)
  .priority(7)
  .send(new Buffer(1024))
  .acknowledge( err => )

an alternative is to be more koa like:

var push = spdy(res).push(path)
push.type = 'json'
push.body = new Buffer(1024)
push.acknowledge( err => )

which of the three approaches do you guys prefer? i think i'm leaning towards the fluent approach.

[dougwilson]

What is the acknowledge thing? an event? without the acknowledge (since I'm not clear on what it is), I would prefer:

spdy(res).push(path, body, {
  type: 'json',
  priority: 7
})

I'm not familiar enough to know which things are optional and which are not, though.

[jonathanong]

haha i'm going to look it up right now. i think it's when the server acknowledges that the push stream is created.

[jonathanong]

http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3-1#TOC-2.6.2-SYN_REPLY

[jonathanong]

it's also optional, so we would allow users to not even bother with acknowledge(). i also wanted to add a different, optional method of .finish() for when the entire stream is finished pushing.

[dougwilson]

if people don't always need to know if it was ack'd, it seems like it would be an event:

var resource = spdy(res).push(path, body, {
  type: 'json',
  priority: 7
})

resource.on('acknowledge', fn)
resource.on('finish', fn)

[jonathanong]

yeah i'm trying to get away from event emitters. hahaha.

[jonathanong]

i also want to return a promise so you can just do yield resource.acknowledge() or yield resource.finish()

[dougwilson]

gotcha :) i'm not saying i like ees, but i typically try to stay with the node.js core paradigms

[jonathanong]

ya maybe i'll just add it anyways. won't know for sure what people want until i release something.

[rlidwka]

Why do you like promises so much? I mean, all use-cases are covered with callbacks and generators. And promises seem to get in the way of chaining api too much.

In this case eventemitter+chaining api fits better imho.

[jonathanong]

because then i could use generators on them and people who don't use generators can still use them. and they'll be compatible with await/async stuff

[jonathanong]

okay i added basic stuff. need to add callback and event support next