ple header fields with the same field name
for all field values defined as comma separated lists, and for
set-cookie.
So you can't feed it straight into dict, unless you place a
requirement on the server to always fold together multiple header
fields with the same field
"
I'm worried that folk will assume a parallel between ASGI and asyncio,
but there appears to be none... which is only a problem due to the
room for confusion.
-Rob
--
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud
like as I like consistency.
For consistency, why not a dict unicode -> List[bytes]
?
-Rob
--
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.
pose, but thats a small subset of the implementations
of WSGI>
-Rob
--
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
https://
n to introducing *something* that fills
> the WSGI role for applications that use asynchronous Python frameworks.
>
> Exactly how this would look is unclear at this stage, and this should be
> thought of as a long-term goal for this SIG. Amber Brown is clearly working
> on an ide
e same thread/process
> where the python application is running. And then nothing stop to give the
> socket away to the application and tell to the server to stop to communicate
> with it.
What socket?
Data could be being passed by shm, for instance.
-Rob
--
Robert Collins <
d in the discussion, but please reach out to
> others as well.
>
> I’d really love to come to the end of 2016 with a solid direction for the
> future of web programming in Python. I’m looking forward to working with you
> all on achieving that.
>
> Thanks,
>
> Cory
>
by making standardisation be predicated on
moving something like Django to a new server core. I recall attempts
to move other big frameworks around years ago now, taking a long long
time I think the question of 'how can we enable interop of HTTP
applications in asyncio' is best handled by a dedicate
On 15 October 2014 08:41, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 15 Oct 2014 08:40:05 +1300
Robert Collins
robe...@robertcollins.net wrote:
On 15 October 2014 07:30, Antoine Pitrou solip...@pitrou.net wrote:
On Tue, 14 Oct 2014 09:47:35 -0700
Guido van Rossum gu...@python.org
where it looks just a little different to WSGI, or we can
have a pep-3156 Protocol interface. We can share a bunch of logic
either way - e.g. CONTENT_LENGTH etc, but the mechanics of writing
middleware might be quite different.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP
together by calling protocol.connection_made(transport).
So where would headers etc be supplied to the protocol for reads (and
for outputs)? Since the transport isn't the raw socket, its the bodies
only.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
On 13 October 2014 16:59, PJ Eby p...@telecommunity.com wrote:
On Sun, Oct 12, 2014 at 6:47 PM, Robert Collins
robe...@robertcollins.net wrote:
FWIW I'm totally fine with you bringing together that PEP - as you say
its complementary to what I'm focused on (I believe I even suggested
you might
in
server-specific fashions. Because the world has moved on and we
haven't.
I think A and C are crucial if we want to re-instate a lingua franca
for the current web, in Python. I'd like to address B, because we can.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
to put
in.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
https://mail.python.org/mailman/options/web-sig/archive
finished by the time
we get through whatever process we have here.
What do you want to see changed in the process I'm following?
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
Web-SIG mailing list
Web-SIG
of
normalization into your application. Or write some middleware to do it.
But trying to make normalization a part of a WSGI-style specification is
impossible.
I don't recall proposing that it should be in a WSGI-style spec.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP
believe I even suggested
you might want to do that).
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
https
On 11 October 2014 01:56, Graham Dumpleton graham.dumple...@gmail.com wrote:
I've pushed up
https://github.com/python-web-sig/wsgi-ng/commit/df51d7d6fd4faa4efbe397fda2c323932f967020
which hopefully addresses the process and clarity concerns you
expressed. (If not please help me tweak it
with complaints and wish lists - got to start
somewhere, and having a clear list of the places WSGI has not met
needs would be excellent.
One thing you could do, if you like, is to put a PR together for the
wsgi-ng repo that adjusts README in the light of your feedback.
-Rob
--
Robert Collins rbtcoll
'yield from', and I do not get access to
the writer object.
Any suggestions welcome.
HTH,
Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http
in, and we'll get some
indication together about how well [or otherwise] the basic things
work.
Concurrently, the IETF HTTP wg is now discussing websocket over
HTTP/2, which will provide more data points for the API capabilities
we'll need.
-Rob
--
Robert Collins rbtcoll...@hp.com
On 29 September 2014 08:32, PJ Eby p...@telecommunity.com wrote:
On Sat, Sep 27, 2014 at 5:38 PM, Robert Collins
robe...@robertcollins.net wrote:
I think we're uncovering important assumptions / facts here.
Indeed!
For clarity: I'm not interested in a nice API for HTTP/2. I want
HTTP/2
September 2014 07:55, PJ Eby p...@telecommunity.com wrote:
On Sat, Sep 27, 2014 at 12:20 AM, Robert Collins
robe...@robertcollins.net wrote:
We should capture these design principles somewhere FAQ-like, since
many of the folk participating in this rework weren't part of the
original design
On 27 September 2014 08:21, Benoit Chesneau bchesn...@gmail.com wrote:
On Fri, Sep 26, 2014 at 5:32 AM, Robert Collins robe...@robertcollins.net
wrote:
...
So I propose we drop the write callable, and include a queue based
implementation in the adapter for PEP- code.
-Rob
What would
On 27 September 2014 10:31, PJ Eby p...@telecommunity.com wrote:
On Fri, Sep 26, 2014 at 5:02 PM, Robert Collins
robe...@robertcollins.net wrote:
But perhaps it would be nicer to say:
iterator of headers_dict_or_body_bytes
With the first item yielded having to be headers (or error thrown
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
https://mail.python.org/mailman/options/web-sig/robertc%40robertcollins.net
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
on WAMPv2. Here are a couple of links
...
Interesting. That looks very similar to Mongrel2.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs
).
I think making an empty bytestream flush the headers would be
sufficient, and preserve much of the niceness.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG
(perhaps I'm wrong) but making read
consistent with the io library would be good, I think - particularly
for websockets.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
Web-SIG mailing list
Web-SIG@python.org
On 22 September 2014 00:08, Robert Collins robe...@robertcollins.net wrote:
On 21 September 2014 16:43, Roberto De Ioris robe...@unbit.it wrote:
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
, and writing code
both inside frameworks like Django and Zope3, as well as straight to
WSGI.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org
On 20 September 2014 19:14, Benoit Chesneau bchesn...@gmail.com 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
(or
is there some historical need for it - if so, perhaps we should use
python-dev or some other list) ?
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http
,
so...
Bill
- nothing to see here, move right along, and sorry for the noise.
-Rob
On 21 September 2014 10:19, Robert Collins robe...@robertcollins.net wrote:
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
having a dozen
different comment-documents in the repo.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
https
#ConnectionErrorHandler)
- backwards compat - making sure that straight PEP- apps still
work well when the server connection is HTTP/2
Is anyone interested in collaborating on an update to WSGI to support
HTTP/2's new features?
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged
36 matches
Mail list logo
