Snakelets and WSGI

Wed Oct 13 08:00:44 EDT 2004

[Irmen de Jong]
 >>Pardon my ignorance, but would it be feasible for a server such
 >>as Snakelets to implement both the WSGI API, *and* the existing
 >>'native' API?

Yes, of course.

The choice would between which one to use could even be made at runtime, 
and could differ for each request, e.g. based on cofiguration, request 
parameters, etc.

The code could look something like this

return_html = ['<html>', '<etc>', '</html>']
if use_iterator_interface:
	yield return_html
else:
	write("".join(return_html))
	yield []

 >>If I want this, and I understand WSGI correctly, this would
 >>require something that the WSGI spec calls "WSGI-Middleware".
 >>Right?

No. See code above.

[Robert Brewer]
 > Snakelets are more problematic, because WSGI heavily prefers a "server
 > pull" model over write() calls. You'd probably have to deprecate
 > Snakelets as written (or wrap write() so it queues their output as
 > well), replacing them eventually with a model that yields values rather
 > than calling write().

Hmm, that's a little heavy handed.

Yes, WSGI is designed to "heavily prefer" iterators, for a whole load of 
good reasons.

However, WSGI also recognises that most of the existing thread-based 
frameworks out there would require significant rewrite in order to 
support this, so it explicitly adds support for "legacy" direct read and 
write of IO channels. This legacy support was explicitly added to make 
porting existing frameworks such as Snakelets *much* *much* *much* easier.

Irmen, I really don't expect that you would have a major porting job on 
your hands.

Although if you decide to rewrite Snakelets to take advantage of the 
iterator interface, you might have some significant rewriting to do, but 
this is *not* required.

[Robert Brewer]
 > Middleware would be for things like statistics, content rewriting, and
 > such, which existing servers (and apps) provide, but which are not
 > server-specific. Most commonly, that's going to be services which apply
 > directly to the HTTP stream, not to either your server or your app
 > framework. Looking quickly over Snakelets I don't see many candidates
 > for middleware.

The concept of middleware that is portable between frameworks is a 
future concept. Although it is a future goal that middleware components 
be portable *between frameworks*, that is currently not the case. As 
Paul Boddie says in another message, the current goal is to enable 
portability of frameworks between server environments: a very worthy 
goal, and a major achievement for WSGI if it works.

As for what middleware components, portable or otherwise, could do, read 
Ian Bicking's thoughts on the subject

http://blog.colorstudy.com/ianb/weblog/2004/08/22.html#P150
http://blog.colorstudy.com/ianb/weblog/2004/08/25.html#P151
http://blog.colorstudy.com/ianb/weblog/2004/08/18.html#P148

regards,

-- 
alan kennedy
------------------------------------------------------
email alan:              http://xhaus.com/contact/alan