On Mon, Apr 25, 2011 at 12:07 PM, David Winslow <[email protected]> wrote: > Hi all, > I work on GeoNode (http://geonode.org/). We're using OWSLib to fetch data > from GeoNetwork. Recently I've discovered that due to the way GeoNetwork > handles sessions, it makes a big difference for us to include HTTP cookies > on our service requests (without them, GeoNetwork creates a new session for > each service request and eventually locks up after running out of RAM.) > Therefore I would like to modify owslib to use a (persistent) instance of > urllib2.HTTPCookieProcessor when opening URLs, one which I can get a > reference to so that I can log in to GeoNetwork and have owslib use the > session cookie. Ideally, there would be a way to provide my own instance of > urllib2.OpenerDirector which I can customize as needed. > I am currently using a monkey patch to fix this behavior, but it's not the > way I'd like to do things (you can see the diff in GeoNode > here: https://github.com/dwins/geonode/compare/master...csw-cookies ). > For a deeper fix I see basically 3 options: > 1) Use Python's urllib2.install_opener to set a default opener instance to > use, and be careful not to pass arguments into owslib methods that would > cause them to create their own openers (for example, including a username > and password in a call to owslib.util.openURL). > 2) Create a module-level variable (owslib.util.opener) and modify > owslib.util.openURL and owslib.util.http_post to reference it exclusively. > Then client code which needs to modify the HTTP handling behavior can > simply replace this variable. > 3) Make each client class (ie, owslib.csw.CatalogueServiceWeb) use its own > opener instance which may be provided by client code. > The attached patch is a partial implementation of approach #3. (In each of > these cases there is the question of how to handle the username/password > arguments to owslib.util.openURL, I haven't addressed this.) > Is this sort of thing something the OWSLib community would be interested in > incorporating? If so I'm happy to update this patch to incorporate feedback > etc.
Hi David, #3 sounds right to me, I've seen this optional callable parameter pattern in other APIs - simplejson's object_hook, for example. -- Sean _______________________________________________ Community mailing list [email protected] http://lists.gispython.org/mailman/listinfo/community
