> When the object receiving the request is ready to send a response, it
> calls…something (sendResponse?) and provides an object implementing a server
> IResponse. The code in the H2Stream/H2Connection sends the headers, then
> calls deliverBody on the IResponse, passing H2Connection (again via
After having written the following comments, I realized that my thoughts
are only about the high-level interface of Site/Resource. I think those
are the interfaces most users care about, so what it makes most sense to
think deeply about having a painless transiftion for. I suspect that if
people ar
> On Nov 19, 2015, at 3:50 AM, Cory Benfield wrote:
>
>
>> On 18 Nov 2015, at 12:18, Glyph Lefkowitz wrote:
>>
>
> Sorry about the delay in responding to this, but I wanted to make sure I knew
> at least a bit about what I was talking about before I responded!
Clearly this is a challenging
> On 19 Nov 2015, at 11:50, Cory Benfield wrote:
> This seems super-gross but vaguely do-able, and we’ll need to write it in
> order to get the new H2Connection/H2Stream objects working with the old
> paradigm anyway.
>
> All of this approach sounds reasonable modulo some careful thinking abou
> On 18 Nov 2015, at 12:18, Glyph Lefkowitz wrote:
>
Sorry about the delay in responding to this, but I wanted to make sure I knew
at least a bit about what I was talking about before I responded!
>> What do people think of this approach?
>
> So I think you're roughly on the right track but
> On 18 Nov 2015, at 12:30, Glyph Lefkowitz wrote:
>
> So the receiver sends explicit "unchoke" messages to increase the window, and
> the "choke" message is implicit?
Modulo some irrelevant distinctions, yes.
Cory
signature.asc
Description: Message signed with OpenPGP using GPGMail
__
> On Nov 18, 2015, at 2:28 AM, Cory Benfield wrote:
>
>
>> On 18 Nov 2015, at 05:55, Glyph Lefkowitz wrote:
>>
>> Does HTTP2 have choke/unchoke notifications on individual streams?
>> Ultimately this does resolve to TCP backpressure, though…
>
> Not in such a binary form, no. The connectio
> On Nov 13, 2015, at 4:36 AM, Cory Benfield wrote:
>
> Folks,
>
> # Problem Statement
>
> Thanks for your feedback on my HTTP/2 questions. I’ve started work
> implementing a spike of a HTTP/2 protocol for twisted.web. I’m aiming to have
> something that works in at least some cases by the e
> On 18 Nov 2015, at 05:55, Glyph Lefkowitz wrote:
>
> Does HTTP2 have choke/unchoke notifications on individual streams?
> Ultimately this does resolve to TCP backpressure, though…
Not in such a binary form, no. The connection as a whole and each stream
maintain independent flow control win
> On Nov 17, 2015, at 3:17 PM, Tobias Oberstein
> wrote:
>
> Am 17.11.2015 um 11:49 schrieb Cory Benfield:
>>
>>> On 15 Nov 2015, at 10:18, Tobias Oberstein
>>> wrote:
>>>
>>> How does flow-control work with the Go API? How does user code processing
>>> chunks received unleash backpressure
Am 17.11.2015 um 11:49 schrieb Cory Benfield:
On 15 Nov 2015, at 10:18, Tobias Oberstein wrote:
How does flow-control work with the Go API? How does user code processing
chunks received unleash backpressure onto the sender?
One caveat: I am not an expert in what Go is doing here, more a ca
> On Nov 17, 2015, at 2:49 AM, Cory Benfield wrote:
>
> Generally speaking in Twisted we could achieve this too, by careful use of
> Deferreds.
I have a bigger reply coming; however, I should note that this is basically
what web2 did with its IStream interface. While this has a big advantage
> On 15 Nov 2015, at 10:18, Tobias Oberstein
> wrote:
>
> How does flow-control work with the Go API? How does user code processing
> chunks received unleash backpressure onto the sender?
One caveat: I am not an expert in what Go is doing here, more a casual user.
However, my understanding i
> On Nov 16, 2015, at 8:03 AM, Michael Schlenker wrote:
>
> One topic: What should happen if the sender sends malformed data (e.g.
> content-length: 100 and sending 200 bytes body). I would usually want to
> know if the sender is broken instead of getting a responseComplete()
> that claims every
Hi Cory,
> On Nov 13, 2015, at 6:36 AM, Cory Benfield wrote:
>
> Folks,
>
> # Problem Statement
>
> Thanks for your feedback on my HTTP/2 questions. I’ve started work
> implementing a spike of a HTTP/2 protocol for twisted.web. I’m aiming to have
> something that works in at least some cases
Hi,
sounds like a good idea.
One topic: What should happen if the sender sends malformed data (e.g.
content-length: 100 and sending 200 bytes body). I would usually want to
know if the sender is broken instead of getting a responseComplete()
that claims everything is fine.
We simply subclassed t
We should then move to an API that is much more like the one used by Go:
specifically, that by default all requests/responses are streamed.
> Request objects (and, logically, any other object that handles
requests/responses, such as Resource) should be extended to have a
chunkReceived method
>
On Sat, 14 Nov 2015 at 17:45 Cory Benfield wrote:
> A similar approach should be taken with sending data: we should assume
> that users want to chunk it if they do not provide a content-length. An
> extreme position to take (and I do) is that this should be sufficiently
> easy that most users act
> What do people think of this approach?
It sounds fine to me.
I think this issue in Twisted is currently the blocker (or at least
*one of* the blockers) for Tahoe-LAFS ticket #113, #320, and #1032. It
is also a blocker for the much more ambitious Tahoe-LAFS tickets #1288
and #1851.
Regards,
Zo
Folks,
# Problem Statement
Thanks for your feedback on my HTTP/2 questions. I’ve started work implementing
a spike of a HTTP/2 protocol for twisted.web. I’m aiming to have something that
works in at least some cases by the end of the day.
As part of my dive into twisted.web, I noticed somethin
20 matches
Mail list logo
