>
> I've proposed using github issues instead of documents; we can
> synthesis the issues into prose in the draft docs and reference code
> itself. I think this will be easier to manage than having a dozen
> different comment-documents in the repo.
>
> -Rob
>
I completely agree and i have already
On 09/20/2014 06:43 PM, Robert Collins wrote:
On 21 September 2014 06:15, Randy Syring wrote:
I'd suggest a "wsgi comments" github repo.
So in the interests of getting things done and the spirit of EAFP I've
set up https://github.com/python-web-sig/wsgi-ng.
Thanks for taking the initiative
On 11 September 2014 06:41, Collin Anderson wrote:
> Hi All,
>
> The CGI spec says:
>
> Script authors should be aware that the REMOTE_ADDR and REMOTE_HOST
> meta-variables (see sections 4.1.8 and 4.1.9) may not identify the
> ultimate source of the request. They identify the client for the
> imm
On 21 September 2014 06:15, Randy Syring wrote:
>
> I'd suggest a "wsgi comments" github repo.
So in the interests of getting things done and the spirit of EAFP I've
set up https://github.com/python-web-sig/wsgi-ng. Since I have no deep
history in web-sig, I'll happily hand out 'organisation adm
Ugh - this was in my mailbox shortly after the moderator action email
from mailman:
"No, this looks like the spam filter. Don't know what triggered it. Or
why it went to you. But the list moderation is turned off (except for
non-members posting to the list), and you yourself are not moderated,
I'm not sure of the right place to bring this up - I tried to on the
web-sig list itself, but the moderator rejected the post.
What I tried to post there was
"""Looks like *every* post to web-sig gets manually moderated. That seems
like it will make discussion rather hard: can we get that changed
On 09/20/2014 02:31 AM, Graham Dumpleton wrote:
The problem with trying to overhaul WSGI is that if it is done in an open forum
like the Web-SIG it will die of a thousand cuts, as past efforts to update it
in even minor ways have suffered.
The only way that WSGI itself will ever see an overha
Hi Benoit,
> I actually wonder if websockets or other asynchronous protocols should be
> handled by the new WSGI SPEC. Shouldn't we just standardize the way the
> socket is given to another library?
>
Considering the websocket connection is initiated via a HTTP request, it
would be a good ide
On 20 September 2014 15:17, Benoit Chesneau wrote:
> 1) HTTP 1.1 vs HTTP 2:
>
> - HTTP 1.1 and HTTP2 have quite the same high level syntax (methods, uri,
> headers, ...) but the way the data is transported differs. (data are sent by
> frames in HTTP 2).
Yes, this is correct. *In principle*, much
got an idea. What about having a page collecting feedback from anyone in
the python community about this topic. So we can have true data from
different perspectives: developer, library/framework author, server author.
I'm OK to collect the data from it and make a summary of it once it's done.
The
On Sat, Sep 20, 2014 at 3:22 PM, Dirkjan Ochtman wrote:
> On Sat, Sep 20, 2014 at 9:23 AM, Robert Collins
> wrote:
> > Well, thats certainly a challenge :). Whats the governance model here?
> > Is a PEP appropriate, and if so - that gives us a BFDL or BFDL
> > PEP-delegate to decide between bike
On Sat, Sep 20, 2014 at 9:23 AM, Robert Collins
wrote:
> Well, thats certainly a challenge :). Whats the governance model here?
> Is a PEP appropriate, and if so - that gives us a BFDL or BFDL
> PEP-delegate to decide between bikeshed issues; and if its not a
> bikeshed issue then resolving it is
On 20 September 2014 08:23, Robert Collins wrote:
> I will happily discuss stuff with you off-list, but I'm not
> particularly interested in having the primary effort be cabal style -
> HTTP/2 has managed to go through a much harder rev with very strong
> personalities and much the same sort of de
On 20 September 2014 19:14, Benoit Chesneau wrote:
> Hi,
>
> I would prefer to have this work being done transparently. If we do it
> rationally it could work imo.
>
> Anyway before thinking to change the protocol or criticizing it maybe we
> could first collect the requirements in HTTP 2 (stream
On 20 September 2014 18:31, Graham Dumpleton wrote:
>
> On 20/09/2014, at 3:49 PM, Roberto De Ioris wrote:
>
>> I can help a bit (i am the uWSGI lead developer and a nginx and Cherokee
>> contributor, and i have already implemented a spdy3 server last year)
>>
>> I honestly think that WSGI by its
Hi,
I would prefer to have this work being done transparently. If we do it
rationally it could work imo.
Anyway before thinking to change the protocol or criticizing it maybe we
could first collect the requirements in HTTP 2 (stream and such) so we can
think about possible implementations. And s
16 matches
Mail list logo
