[owslib-devel] WPS initialization

[Tom Kralidis]

Hi Luca: how does (basically) something like the below work for you?

Index: owslib/wps.py
===================================================================
--- owslib/wps.py       (revision 1873)
+++ owslib/wps.py       (working copy)
@@ -161,7 +161,7 @@
     Implements IWebProcessingService.
     """
     
-    def __init__(self, url, version=WPS_DEFAULT_VERSION, username=None, password=None, verbose=False):
+    def __init__(self, url, version=WPS_DEFAULT_VERSION, username=None, password=None, verbose=False, skip_caps=False):
         """
         Initialization method resets the object status, it does NOT execute a GetCapabilities invocation to the remote service.
         """
@@ -179,6 +179,9 @@
         self.provider = None
         self.operations=[]
         self.processes=[]
+
+        if not skip_caps:
+            self.getcapabilities()
         
     def getcapabilities(self, xml=None):
         """

...or whatever way you'd like to ensure the desired behaviour.  If you commit and update tests/docs, I can test as well.

Thanks

..Tom


----------------------------------------
> From: Luca.Cinquini at jpl.nasa.gov
> To: tomkralidis at hotmail.com
> CC: owslib-devel at lists.sourceforge.net
> Subject: Re: [owslib-devel] WPS initialization
> Date: Thu, 7 Jun 2012 13:00:32 +0000
>
> Hi Tom,
> thanks for checking this out...
>
> My thought on the subject was that a GetCapabilities call is only needed to inspect a service the very first time you start interacting with it... but after that, when you already know what kind of process you want to submit, it is not indeed, and in-fact it just an extra HTTP request/response. For example, the UI for a portal that submits requests to remote WPS will already have the allowed processes coded in as part of its options, without the need to request them every single time.
>
> That said, if you think it is important to keep consistency with the other OWSlib clients behavior, we can make the GetCapabilities call happen every time at service initialization, and possibly insert the same opt-out option you have in CSW.
> Let me know - or feel free to change the code if you'd like.
>
> thanks, Luca
>
> On Jun 7, 2012, at 6:52 AM, Tom Kralidis wrote:
>
> >
> >
> > Luca: just checking out the great work on WPS (I'll be using this for CSW harvesting of WPS in pycsw) and have a question/comment:
> >
> >>>> from owslib.wps import WebProcessingService
> >>>> wps = WebProcessingService('http://cida.usgs.gov/climate/gdp/process/WebProcessingService', verbose=False)
> >>>> wps.getcapabilities()
> >
> > Typically in OWSLib, we have invoked a GetCapabilities request when the constructor is called (negating the need for an extra getcapabilities() call). At the same time, I see the value of not calling GetCapabilities right away (in the CSW module, I've added the skip_caps parameter).
> >
> > What do you think of calling capabilities as part of the constructor? This would unify things with the rest of the codebase behaviour on init. We could leave wps.getcapabilities() in there, which a user can call later, if wps is init'd with something like skip_caps.
> >
> > Thoughts? Thanks for the consideration.
> >
> > ..Tom
> >
> >
> > ------------------------------------------------------------------------------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond. Discussions
> > will include endpoint security, mobile security and the latest in malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > owslib-devel mailing list
> > owslib-devel at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/owslib-devel
>