Re: [Web-SIG] Inviting feedback on my proposed "ASGI" spec

[Ionel Maries Cristian]

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" would be some sort of specialized proxy service that does the
websocket routing, proxying plain requests to the worker (for the regular
views) and specific frontend protocol handling (upgrading to
http2.0/websockets or whatever).
It would be more clear if the docs would include some diagrams illustrating
data flow and how all the components connect together with what protocols.

Shouldn't the process type "that handles HTTP and WebSockets" have a more
specific term? It's a bit long to type.

Spec is up here: http://channels.readthedocs.org/en/latest/asgi.html
>

Is ASGI a wire protocol? I'd assume it is, if multiple processes
communicate to each other with this protocol, but the docs don't have any
details about the exact wire format.

Also, some comparison to existing solutions (like Meteor/SockJS/Crossbar
/WAMP ) would help clearing
lots of questions.

​[1] Sorry if it sounds harsh, certainly not the intention. I'm just a bit
confused/overwhelmed.​

Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
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%40mail-archive.com

Re: [Web-SIG] A Python Web Application Package and Format

[Ionel Maries Cristian]

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 appengine it should be more
   flexible in this regard and offer a way to generate the project dependencies
   somewhere else than the depeloper's machine.
   - There's no builtin support for logging configuration.
   - The update_fetch feels like a hack as it's not extensible to do
   lifecycle (hooks for shutdown, start, etc). Also, it's shouldn't be a
   application url because you'd want to run a hook before starting it or after
   stopping it. I guess you could accomplish that with a wsgi wrapper but there
   should be a clear separation between the app and hooks that manage the app.
   - I'm not entirely clear on why you avoid a build process (war-like)
   prior to deployment. It works fine for appengine - but you don't have it's
   constraints.

-- Ionel



On Fri, Apr 1, 2011 at 23:55, Ian Bicking  wrote:

> Hi all.  I wrote a blog post.  I would be interested in reactions from this
> crowd.
>
> http://blog.ianbicking.org/2011/03/31/python-webapp-package/
>
> Copied to allow responses:
>
> At PyCon there was an open space about deployment, and the idea of drop-in
> applications 
> (Java-WAR-style
> ).
>
> I generally get pessimistic about 80% solutions, and dropping in a WAR file
> feels like an 80% solution to me. I’ve used the Hudson/Jenkins installer
> (which I think is *specifically* a project that got WARs on people’s
> minds), and in a lot of ways that installer is nice, but it’s also kind of
> wonky, it makes configuration unclear, it’s not always clear when it
> installs or configures itself through the web, and when you have to do this
> at the system level, nor is it clear where it puts files and data, etc. So a
> great initial experience doesn’t feel like a great ongoing experience to me
> — and *it doesn’t have to be that way*. If those were *necessary*compromises, 
> sure, but they aren’t. And because we
> *don’t have* WAR files, if we’re proposing to make something new, then we
> have every opportunity to make things better.
>
> So the question then is what we’re trying to make. To me: we want
> applications that are easy to install, that are self-describing,
> self-configuring (or at least guide you through configuration), reliable
> with respect to their environment (not dependent on system tweaking),
> upgradable, and respectful of persistence (the data that outlives the
> application install). A lot of this can be done by the "container" (to use
> Java parlance; or "environment") — if you just have the app packaged in a
> nice way, the container (server environment, hosting service, etc) can
> handle all the system-specific things to make the application actually work.
>
> At which point I am of course reminded of my Silver 
> Liningproject, which defines something very 
> much like this. Silver Lining isn’t
> *just* an application format, and things aren’t fully extracted along
> these lines, but it’s pretty close and it addresses a lot of important
> issues in the lifecycle of an application. To be clear: Silver Lining is an
> application packaging format, a server configuration library, a cloud server
> management tool, a persistence management tool, and a tool to manage the
> application with respect to all these services over time. It is a bunch of
> things, maybe too many things, so it is not unreasonable to pick out a
> smaller subset to focus on. Maybe an easy place to start (and good for
> Silver Lining itself) would be to separate at least the application format
> (and tools to manage applications in that state, e.g., installing new
> libraries) from the tools that make use of such applications (deploy, etc).
>
> Some opinions I have on this format, exemplified in Silver Lining:
>
>- It’s not zipped or a single file, unlike WARs. Uploading zip files is
>not a great API. Geez. I know there’s this desire to "just drop in a file";
>but there’s no getting around the fact that "dropping a file" becomes a
>*deployment protocol* *and* *it’s an incredibly impoverished protocol*.
>The format is also not subtly git-based (ala Heroku) because git pushis 
> not a good deployment protocol.
>- But of course there isn’t really any deployment protocol inferred by
>a format anyway, so maybe I’m getting ahead of myself ;) I’m saying a tool
>that deploys should take as an argument a directory, not a single file. (If
>the tool then zips it up and uploads it, fine!)
>- Configuration "comes from the outside". That is, an application
>requests services, and the *container* tells the application where
>those services are. For Silver Lining I’ve used environmental variables. 

Re: [Web-SIG] PEP 444 (aka Web3)

[Ionel Maries Cristian]

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 start_response once the headers
>> are final. Not perfect, but at least non-blocking. Web3 removes this
>> possibility. The headers must be returned before the body iterable
>> yielded its first element, empty or not.
>>
>> Removing any support for this type of asynchronism would render web3
>> useless for all but completely synchronous and trivial applications.
>> Even frameworks would have no way to work around this anymore.
>>
>
> I'm aware of what a lot of people have done with WSGI, but I'm not aware of
> anyone doing an async proxy of any sort, or implementing anything in a way
> where this empty string policy served any function.  It's not implausible
> that it *could* be used, but years of practice have shown it is not used.
>
> --
> Ian Bicking  |  http://blog.ianbicking.org
>
> ___
> Web-SIG mailing list
> Web-SIG@python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe:
> http://mail.python.org/mailman/options/web-sig/ionel.mc%40gmail.com
>
>
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: 
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com

Re: [Web-SIG] PEP 444 (aka Web3)

[Ionel Maries Cristian]

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 doesn't consume
the body iterable) and it will fail most of the times since you can't just
add a tuple to a iterable.

The missing requirement that middleware must yield at least an empty string
if they need more more information from the application iterable also breaks
async gateways that expect oob information from the app (for example cogen
can't be ported to this spec).

The removed requirement "middleware components *must not* block iteration
waiting for multiple values from an application iterable. If the middleware
needs to accumulate more data from the application before it can produce any
output, it *must* yield an empty string." also breaks async gateways/apps.

I feel this spec puts too much burden on applications - having to process
all those byte strings and even having to add Content-Length even for naive
buffered-body apps.

--ionel



On Thu, Sep 16, 2010 at 02:03, Chris McDonough  wrote:

> A PEP was submitted and accepted today for a WSGI successor protocol
> named Web3:
>
> http://python.org/dev/peps/pep-0444/
>
> I'd encourage other folks to suggest improvements to that spec or to
> submit a competing spec, so we can get WSGI-on-Python3 settled soon.
>
> - C
>
>
> ___
> Web-SIG mailing list
> Web-SIG@python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe:
> http://mail.python.org/mailman/options/web-sig/ionel.mc%40gmail.com
>
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: 
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com

Re: [Web-SIG] Shortening execution time of Python script

[Ionel Maries Cristian]

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 have a Python script that automatically downloads zip files containing
> large datasets from another server and then unzips the files to further
> process the data.
>
> It has been used as a geoprocessor of ArcGIS Server.
>
> The script works fine when two datasets each has several kilobytes size,
> but the script stops half way when datasets were about 11,000KBytes.
>
> I think that the execution time is too long and ArcGIS Server just simply
> killed the process.
>
> What actions can I try to reduce the execution time?
>
> ArcGIS Server only works on the basis of 32 bits and I was told that the
> maximum memory it can utilise is 4 MBytes.
>
> I should be grateful if someone can make suggestions/recommendations.
>
> Sincerely,
>
> David
>
>
> ___
> Web-SIG mailing list
> Web-SIG@python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe:
> http://mail.python.org/mailman/options/web-sig/ionel.mc%40gmail.com
>
>
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: 
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com

Re: [Web-SIG] Closing long-running WSGI requests (possible?)

[Ionel Maries Cristian]

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
a batch a set of queries and you can interleave yielding some data while
you run that batch.

For example if your client disconnects and the servers tries to send some
data
it would fail - and trigger closing the app iterable.

In contrast a server that just runs some backend processing without moving
any data around doesn't have any way to know if the connection is still
valid.

Then again, even if the client properly shutdown the connection the server
won't do anything about it if it doesn't try to do anything with the socket
due
to the synchronous nature (I'm assuming) of the whole server/app.

-- ionel



On Mon, Apr 13, 2009 at 17:53, Christian Wyglendowski
wrote:

> On Mon, Apr 13, 2009 at 10:40 AM, Chimezie Ogbuji  wrote:
> > Hello.  I have a problem with a WSGI-based SPARQL server that I have been
> > unable to resolve for some time.  I was told this is the best place to
> ask
> > :).  I'm building a SPARQL [1] server that is deployed as  WSGI/Paste
> > server.  SPARQL queries are handled by the server and evaluated against a
> > MySQL database using mysql-python/MySQLdb to manage the connection.
> >
> > My goal is to be able to allow clients to close the connection in order
> to
> > kill queries that have been dispatched (in order to 'abort' them).
>
> This should be doable from what I understand.  From PEP 333:
>
> "If the iterable returned by the application has a close() method, the
> server or gateway must call that method upon completion of the current
> request, whether the request was completed normally, or terminated
> early due to an error. (This is to support resource release by the
> application. This protocol is intended to complement PEP 325's
> generator support, and other common iterables with close() methods."
> [1]
>
> So it sounds like you could add a close method on whatever iterable
> that your application returns and have it do the required resource
> release there.
>
> HTH,
>
> Christian
> http://www.dowski.com
>
> [1] http://www.python.org/dev/peps/pep-0333/#specification-details
> ___
> Web-SIG mailing list
> Web-SIG@python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe:
> http://mail.python.org/mailman/options/web-sig/ionel.mc%40gmail.com
>
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: 
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com

Re: [Web-SIG] WSGI Open Space @ PyCon.

[Ionel Maries Cristian]

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
>>> 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 could be to appear like an empty string. Thus a
>>> middleware would see it as an empty string. Of course, the WSGI
>>> middleware then may suppress it and not pass it back down the line.
>>>
>>> As with wsgi.file_wrapper, the problem is that only the WSGI adapter
>>> really knows what the type of the iterable instance being returned is,
>>> a WSGI middleware can't work it out, except maybe by creating a dummy
>>> instance of one and comparing the types. Even then, that may not be
>>> guaranteed.
>>>
>>> This therefore makes it hard for a WSGI middleware to even detect such
>>> special control/meta elements and simply pass them through. That also
>>> wouldn't work anyway, as a WSGI middleware could be trying to combine
>>> together all the strings into one big string to stick a content length
>>> on it. In that case it isn't going to even know that a special control
>>> element is saying that it should stop trying to do that and instead
>>> flush out what it has already accumulated so that underlying server
>>> can do other stuff while waiting for file descriptor to be ready.
>>>
>>> A WSGI middleware doing this sort of thing is going to screw you up
>>> even if empty string as might be getting used for this purpose now. In
>>> short, I can't see how you can do it this way, as you have no
>>> guarantee that a WSGI middleware will not hold on to it. Thus never
>>> gets back to underlying WSGI adapter.
>>>
>>
>> That's wrong - middleware should not eat up response chunks.
>>
>> To quote the wsgi spec:
>>       To put this requirement another way, a middleware component
>>       must yield at least one value each time its underlying application
>>       yields a value. If the middleware cannot yield any other value,
>>       it must yield an empty string.
>> See:
>> http://www.python.org/dev/peps/pep-0333/#middleware-handling-of-block-boundaries
>
> In practice I doubt that that is being applied consistently and you
> thus can't rely on it.
>
> Even so, any WSGI middleware still needs a way of detecting these
> control/meta elements and know it has to pass them through straight
> away. They can't just pass back an empty string in place of them as
> that defeats the purpose of them.
>
> Graham
>

Meta/control elements could be saved somewhere on a special object
in the environ and empty strings can just be a notification we need to
check that object for the meta/control element.
This way should penetrate all middleware that comply to the rules in the
wsgi spec.

There is not so much middleware that breaks this - I only know of error
capturing middleware - but those are acceptable offenders. Either way,
it's easy to fix.

-- ionel
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: 
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com

Re: [Web-SIG] WSGI Open Space @ PyCon.

[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
> 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 could be to appear like an empty string. Thus a
> middleware would see it as an empty string. Of course, the WSGI
> middleware then may suppress it and not pass it back down the line.
>
> As with wsgi.file_wrapper, the problem is that only the WSGI adapter
> really knows what the type of the iterable instance being returned is,
> a WSGI middleware can't work it out, except maybe by creating a dummy
> instance of one and comparing the types. Even then, that may not be
> guaranteed.
>
> This therefore makes it hard for a WSGI middleware to even detect such
> special control/meta elements and simply pass them through. That also
> wouldn't work anyway, as a WSGI middleware could be trying to combine
> together all the strings into one big string to stick a content length
> on it. In that case it isn't going to even know that a special control
> element is saying that it should stop trying to do that and instead
> flush out what it has already accumulated so that underlying server
> can do other stuff while waiting for file descriptor to be ready.
>
> A WSGI middleware doing this sort of thing is going to screw you up
> even if empty string as might be getting used for this purpose now. In
> short, I can't see how you can do it this way, as you have no
> guarantee that a WSGI middleware will not hold on to it. Thus never
> gets back to underlying WSGI adapter.
>

That's wrong - middleware should not eat up response chunks.

To quote the wsgi spec:
   To put this requirement another way, a middleware component
   must yield at least one value each time its underlying application
   yields a value. If the middleware cannot yield any other value,
   it must yield an empty string.
See:
http://www.python.org/dev/peps/pep-0333/#middleware-handling-of-block-boundaries


-- ionel
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: 
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com

Re: [Web-SIG] Proposed WSGI extensions for asynchronous servers

[Ionel Maries Cristian]

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 wsgi.input.
> >
> > That is, you will need a way for this spec to support middleware that's
> > replacing wsgi.input, without the middleware knowing that this specification
> > exists.  In the worst case, it should detect the replaced input and give an
> > error or some response that lets the application know it won't really be
> > able to use the async feature.
> >
>
> I hadn't considered middleware that replaces wsgi.input.  Is there an
> example component you can point me to, just so I have something concrete to
> look at?
>
> Given that the semantics of wsgi.input are, in general, incompatible with
> non-blocking execution, I'm inclined to think that such middleware would
> either need to be rewritten to use x-wsgiorg.async.input, or just couldn't
> be used with asynchronous servers.  But I'll think about it some more --
> maybe there's a way to make this work.
>


Making input filters work could be achieved using greenlets - but then again
- if one would use greenlets he could use them to simulate a seemingly
blocking api for the input so this is pretty much pointless.

But I agree, detecting this is good and errors should be thrown in this
case.
In cogen i'm setting wsgi.input to None - so any use of it would end in a
error - though it's not very elegant.


-- 
http://ionelmc.wordpress.com
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: 
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com

Re: [Web-SIG] Proposed WSGI extensions for asynchronous servers

[Ionel Maries Cristian]

> 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, then I see
> the problem.
>
> The solution would probably be for the application to pass a mutable
> object (e.g. an empty list) to readable/writable that the server could set a
> timeout flag on.
>

How about a environ['x-wsgiorg.async'].timeout ? I do something like that in
cogen.

-- 
http://ionelmc.wordpress.com
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: 
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com

Re: [Web-SIG] Proposal for asynchronous WSGI variant

[Ionel Maries Cristian]

 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,
> >
> Why is readline a requirement for chunked input?  Each chunk specifies its
> size, and the application receiving a chunk just keeps calling recv() until
> it's read the specified number of bytes.
>

Well, not really a requirement, i was implying there is some sort of
readline since that is what one would generaly use some sort of realine to
get the size of a chunk - but not necessarily.


>   also, it should be the gateway's business decoding the chunked input.
> >
> OK, but if it's the gateway's responsibility, then this isn't an issue at
> all, as decoding of chunked data takes place before the application ever
> sees the request body.
> To be clear, I didn't mean to imply that awsgi.input must be the actual
> socket object connected to the client.  It just has to provide a recv()
> method with the semantics of a socket.  The server is free to pre-read the
> entire request, or it can receive data on demand, decoding any chunked input
> before it passes it to the application.
>


>  - i don't see how removing the write callable will help (i don't see a
> > issue having the server providing a stringio.write as the write callable for
> > synchronous apps)
> >
> Manlio explained this well, so I'll refer you to his response.
>
> > - passing nonstring values though middleware will make using/porting
> > existing wsgi middleware hairy (suppose you have a middleware that applies
> > some filter to the appiter - you'll have your code full of isinstance
> > nastiness)
> >
> Yes, my proposal would require existing middleware to be modified to
> support AWSGI, which is unfortunate.
>
> > Also, have you looked at the existing gateway implementations with
> > asynchronous support? There are a bunch of them:
> > http://trac.wiretooth.com/public/wiki/asycwsgi
> > http://chiral.j4cbo.com/trac
> > http://wiki.secondlife.com/wiki/Eventlet
> > my own shot at the problem: http://code.google.com/p/cogen/
> > and manlio's mod_wsgi for nginx
> > (I may be missing some)
> >
> I've seen some of these, but I'll be sure to take a look at the others.
>
> > [*1]In my implementation i do a bunch of tricks to make use of regular
> > wsgi middleware with async apps possible - i have a bunch of working
> > examples using pylons:  - the extensions in the environ (like your
> > environ['awsgi.readable']) return a empty string that penetrates most[*2]
> > middleware and set the actual message (like your (token, fd, timeout) tuple
> > on some internal object)
> > From this point of view, an async middleware stack is just a set of
> > middleware that supports streaming.
> >
> This is an interesting idea that I'd like to explore some more.  I really
> like the fact that it works with existing middleware (or at least fully
> WSGI-compliant middleware, as you point out).
> Apart from the write() callable, the biggest issue I see with the WSGI
> spec for asynchronous servers is wsgi.input.  The problem is that this is
> explicitly a file-like object.  This means that input.read(n) reads until it
> finds n bytes or EOF, input.readline() reads until it finds a newline or
> EOF, and input.readlines() and input.__iter__() always read to EOF.  Every
> one of these functions implies multiple I/O operations (calls to fread() for
> a file or recv() for a socket).
>  This means that if an application calls input.read(8), and only 4 bytes
> are available, the first call to recv() returns 4 bytes, and the second one
> blocks.  And now your entire server is blocked until data is available on
> this one socket.   (Of course, the server is free to pre-read the entire
> request at its leisure and feed it to the application from a buffer, but
> this may not always be practical or desirable, and I don't think
> asynchronous servers should be forced to do so.)
>  This is why I propose replacing wsgi.input with awsgi.input, which
> exposes a recv() method with socket-like (rather than file-like) semantics.
>  The meaning of input.recv(n) is therefore "read at most n bytes (possibly
> less), calling the underlying socket recv() at most one time".
>  So, although your suggestion may eliminate the need to yield non-string
> output from the application iterable, I still think there needs to be a
> separate specification for asynchronous gateways, since the semantics of
> wsgi.input ju

Re: [Web-SIG] Proposal for asynchronous WSGI variant

[Ionel Maries Cristian]

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 support for streaming and
asynchronicity [*1]
- i don't see how removing the write callable will help (i don't see a issue
having the server providing a stringio.write as the write callable for
synchronous apps)
- passing nonstring values though middleware will make using/porting
existing wsgi middleware hairy (suppose you have a middleware that applies
some filter to the appiter - you'll have your code full of isinstance
nastiness)

Also, have you looked at the existing gateway implementations with
asynchronous support?
There are a bunch of them:
http://trac.wiretooth.com/public/wiki/asycwsgi
http://chiral.j4cbo.com/trac
http://wiki.secondlife.com/wiki/Eventlet
my own shot at the problem: http://code.google.com/p/cogen/
and manlio's mod_wsgi for nginx
(I may be missing some)

However there is absolutely no unity in handling the wsgi.input (or
equivalent)

[*1]In my implementation i do a bunch of tricks to make use of regular wsgi
middleware with async apps possible - i have a bunch of working examples
using pylons:
 - the extensions in the environ (like your environ['awsgi.readable'])
return a empty string that penetrates most[*2] middleware and set the actual
message (like your (token, fd, timeout) tuple on some internal object)
>From this point of view, an async middleware stack is just a set of
middleware that supports streaming.

Please see:
 http://cogen.googlecode.com/svn/trunk/docs/cogen.web.async.html
http://cogen.googlecode.com/svn/trunk/docs/cogen.web.wsgi.html


[*2] middleware that consume the app iter ruin that pattern, but regardless,
they are not compliant to the wsgi spec (see
http://www.python.org/dev/peps/pep-0333/#middleware-handling-of-block-boundaries
)
- notable examples are most of the exception handling middleware (they can't
work otherwise anyway)

On Tue, May 6, 2008 at 4:30 AM, Christopher Stawarz <[EMAIL PROTECTED]>
wrote:

> (I'm new to the list, so please forgive me for making my first post a
> specification proposal :)
>
> Browsing through the list archives, I see there's been some
> inconclusive discussions on adding better support for asynchronous web
> servers to the WSGI spec.  Since such support would be very useful for
> some upcoming projects of mine, I decided to take a shot at specing
> out and implementing it.  I'd be grateful for any feedback you have.
> If this seems like something worth pursuing, I would also welcome
> collaborators to help develop the spec further.
>
> The name for this proposed specification is the Asynchronous Web
> Server Gateway Interface (AWSGI).  As the name suggests, the spec is
> closely related to WSGI and is most easily described in terms of how
> it differs from WSGI.  AWSGI eliminates the following parts of WSGI:
>
>  - the environment variables wsgi.version and wsgi.input
>
>  - the write() callable returned by start_response()
>
> AWSGI adds the following environment variables:
>
>  - awsgi.version
>  - awsgi.input
>  - awsgi.readable
>  - awsgi.writable
>  - awsgi.timeout
>
> In addition, AWSGI allows the application iterable to yield two types
> of data:
>
>  - byte strings, handled as in WSGI
>
>  - the result of calling awsgi.readable or awsgi.writable, which
>indicates that the application should be paused and restarted when
>a specified file descriptor is ready for reading or writing
>
> Because of AWSGI's similarity to WSGI, a simple wrapper can be used to
> run AWSGI applications on WSGI servers without alteration.
>
> The following example application demonstrates typical usage of AWSGI.
> This application simply reads the request body and sends it back to
> the client.  Each time it wants to receive data from the client, it
> first tests awsgi.input for readability and then calls its recv()
> method.  If awsgi.input is not readable after one second, the
> application sends a "408 Request Timeout" response to the client and
> terminates:
>
>
>  def echo_request_body(environ, start_response):
>  input = environ['awsgi.input']
>  readable = environ['awsgi.readable']
>
>  nbytes = int(environ.get('CONTENT_LENGTH') or 0)
>  output = ''
>  while nbytes:
>  yield readable(input, 1.0)  # Time out after 1 second
>
>  if environ['awsgi.timeout']:
>  msg = 'The request timed out.'
>  start_response('408 Request Timeout',
> [('Content-Type', 'text/plain'),
>  ('Content-Length', str(len(msg)))])
>  yield msg
>  return
>
>  data = input.recv(nbytes)
>  if not data:
>  break
>  output += data
>  nbytes -= len(data)
>
>  start_response('200 OK', [('Content

[Web-SIG] app iterable containing non-strings

[Ionel Maries Cristian]

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 mechanism for server extensions.
(besides the environ)

-- 
http://code.google.com/p/cogen/
ionel.
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: 
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com

[Web-SIG] wsgi.file_wrapper and range requests

[Ionel Maries Cristian]

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
Unsubscribe: 
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com