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 / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
