Hi there, On Thu, Jun 12, 2008 at 8:54 PM, Ian Bicking <[EMAIL PROTECTED]> wrote: > Martijn Faassen wrote: [snip] >> WSGIProxy - unreleased, but recent development activity is a bit younger >> than HTTPEncode. > > I need to clean it up, but generally I would recommend WSGIProxy, and would > not recommend HTTPEncode. For a client > wsgiproxy.exactproxy.proxy_exact_request would be the best app, and it's the > thing least likely to be moved around in WSGIProxy.
Right, I did find proxy_exact_request. Is there any chance WSGIProxy could be released to PyPI any time soon? What kind of cleanups would you like to do? It's just nicer to work with a release than it is to work with an SVN external. >> HTTPEncode also includes some other features I might want to use (the >> encoding bit), though I'm not sure yet. I believe it doesn't allow me to >> use WebOb directly, which needs a WSGI application. > > Nah... the encoding bit is kind of arcane and I think just isn't right. I found it interesting, but didn't study it deeply. In fact I'm playing around with my own lxml-based encoding/decoding story, so I wasn't quite sure how HTTPEncode would fit in. >> Any (paste or non-paste) possibilities I missed? Is client-side WSGI the >> right direction to go? Anything to watch out for? Which one of these is >> recommended for my use case? Should I worry about the lack of releases? > > I think WebOb specifically is a fairly nice client library, though it wasn't > entirely intentional. I've used WebTest (based on WebOb) to do functional > testing over HTTP before in the same manner. Yes, I'm quite interested in testing my client library and looked at WebTest. I'm not sure whether I can use WebTest though as I want to rest my own API which in turn makes HTTP calls. I figured WSGI would be a way to help there - hook it up locally for the tests, and for real use, use WSGIProxy. The Zope publisher has ways to do local functional tests as well without going over HTTP, but it's one of the bits of Zope 3 that pulls in a million other bits, and I didn't want to do that for this pure client-side library. [snip] >> Would it make sense to change HTTPEncode to use WebOb and WSGIProxy? > > Maybe rethinking HTTPEncode would make some sense, but it's kind of too > complex for its own good, especially compared to doing the same things > natively. All for a small saving that could be achieved more easily with > other techniques. WebOb itself uses some HTTPEncode-like ideas for handling > the request body, but it's more conservative about it. All right, thanks for pointing me in the direction of WSGIProxy. It's also good I didn't hear "don't do that!". I realize WebOb wasn't designed as a client library, but it's the one minimal request/response library I could find, and it intends to be a framework independent one. Thanks for the feedback! Regards, Martijn _______________________________________________ Paste-users mailing list [email protected] http://webwareforpython.org/cgi-bin/mailman/listinfo/paste-users
