Hey,
On Thu, Mar 10, 2016 at 2:34 AM, Andrew Godwin wrote:
> Helpful quick Q&A: http://channels.readthedocs.org/en/latest/inshort.html
>
I have looked over that and it's not very clear what goes where. [1] I'd be
inclined to understand that the process type "that handles HTTP and
WebSockets" wo
Hello,
I have few comments:
- That file layout basically forces you to have your development
environment as close to the production environment. This is especially
visible if you're relying on python c extensions. Since you don't want to
have the same environment constraints as appeng
There's a framework called cogen and it relies on this policy.
-- ionel
On Sat, Sep 18, 2010 at 12:34, Ian Bicking wrote:
> On Sat, Sep 18, 2010 at 5:03 AM, Marcel Hellkamp wrote:
>
>> With WSGI it was possible to yield empty strings as long as the
>> application is waiting for data and call s
I don't like this proposal at all. Besides having to go through the bytes
craziness the design is pretty backwards for middleware and asynchronous
applications.
Even the proxy_and_timing_support example in the PEP is broken for async or
streaming apps - it won't return the proper time (since it do
You're a bit contradicting yourself - what's the actual problem, process
memory size or execution time ?
If it's the process memory size you could trick ArcGIS by using a subprocess
that does the actual work (and eats into the memory).
-- ionel
On Wed, Sep 9, 2009 at 13:52, David Shi wrote:
> I
That implies one would have extremely reliable tcp connections, and clients
graciously shutdown the connection and the server is notified of that.
Most of the time that doesn't happen and the solution is to continuously
send
keepalive packets (some small string or whatever) - I'm assuming you run
On Mon, Mar 30, 2009 at 14:14, Graham Dumpleton
wrote:
> 2009/3/30 Ionel Maries Cristian :
>> On Mon, Mar 30, 2009 at 03:13, Graham Dumpleton
>> wrote:
>> [...]
>>
>>> The problem with this is what happens if a WSGI middleware tries to do
>>> somethi
On Mon, Mar 30, 2009 at 03:13, Graham Dumpleton
wrote:
[...]
> The problem with this is what happens if a WSGI middleware tries to do
> something with it. If the separate change is made to allow string like
> objects to be returned instead of only string objects, then its string
> like behaviour
On Mon, May 12, 2008 at 3:25 AM, Christopher Stawarz <[EMAIL PROTECTED]>
wrote:
> On May 11, 2008, at 7:05 PM, Phillip J. Eby wrote:
>
> For this to work, you're going to need this to take the wsgi.input object
> > as a parameter. If you don't, then this will bypass middleware that
> > replaces
> My thinking is that the server *creates* the environ dictionary, so it can
> just keep a reference to it and update it as needed. Is middleware allowed
> to replace environ with another dict instance before passing it to the
> application? I wasn't aware that this was allowed, but if it is, the
On Wed, May 7, 2008 at 10:00 PM, Christopher Stawarz <
[EMAIL PROTECTED]> wrote:
> On May 6, 2008, at 8:51 PM, Ionel Maries Cristian wrote:
>
> > - there is no support for chunked input - that would require having
> > support for readline in the first place,
> >
&
This is a very interesting initiative.
However there are few problems:
- there is no support for chunked input - that would require having support
for readline in the first place, also, it should be the gateway's business
decoding the chunked input.
- the original wsgi spec somewhat has some suppo
I was reading the wsgi spec and i was wondering how should
middleware treat the iterable that happens to contain values
that aren't strings (and I'm not talking about unicodes) - the spec isn't
explicit on this.
If middleware would just pass on values that aren't string
instances - this could be a
wsgi.file_wrapper doesn't support sending a file from a specific offset as
per wsgi spec.
what are your thoughts on this ?
--
http://ionel.zapto.org
ionel.
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscri
14 matches
Mail list logo
