[Web-SIG] Fun with WSGI -- commenting middleware.

[Ian Bicking]

Titus Brown wrote:
> I thought about this a bit more.  I like the proxy idea (and will
> implement it next time I have the urge to do some light coding).  For
> the python docs, though, wouldn't it be better to just host the files
> on the same machine?

Yes, that's possible too, especially since they are all completely 
static and fully rendered.  Probably easier, and also implemented 
already ;)   I'm sure there's others, but wsgikit.urlparser serves 
static files reasonably well (wsgikit.wsgilib.send_file could use some 
work to be more efficient).

> I will probably develop a simple Quixote application to wrap the
> commenting code, too; having all this in CGI will get annoying,
> if I do anything more complex than what I'm doing now.

At one time I did a lot of this kind of thing where you'd read a page 
then fiddle with the output.  It always had some holes, but it's an 
interesting technique, and one I come back to often.

It would be nice to have a mini-framework for this sort of thing, that 
hides a bit of the WSGI fiddling you have to do.  I.e., the framework 
packages up the request (which contains important information like the 
requested URL) and the response, and it gives it to some hook to munge 
the response (like adding comments).  Another one might run the output 
through tidy and tack errors and warnings at the bottom of the page.

Some sort of URL escape would also be good -- i.e., if your munging 
middleware is at /comment_system, then maybe you could tell it to 
redirect /comment_system/foo/* to another application, and that 
application would handle the form action for comments.  That's easy to 
imagine as a Quixote app or something; but the munging bit isn't as easy.

It would be easier if there was a function (which there might be) that 
could turn the WSGI request into a Quixote request object without 
bringing the rest of the framework in.  Then the munging portion 
wouldn't be a Quixote application, per se, but it would look quite similar.

Or, you could turn one request into two, sending the output of the first 
application as input to a second application, e.g., as a POST request 
where the body and headers are put into some fields.  Then it could be a 
normal application, but it seems like a complex way to get there. 
Though... maybe it actually is the best way.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org