I am interested in doing some WPS 1.0 work (but no idea if I will get it). Talking on and off with Simone shows that a few other people are interested in working on WPS this year ...
As such I thought I would share some notes ...
- uDig : Confluence
I would love to talk anyone interested after the GeoServer meeting tomorrow; or as the last topic in the meeting.
Jody
PS. I ended up using the uDig wiki since the geoserver wiki is in flux; and I am considering the end to end solution
Hi Jody,
Sounds pretty darn exciting. WPS is something that has recently moved up my list of stuff I would like to see implemented. Chris and I chatted a bit about it this week.
I glanced over your notes, and yeah, for sure lets make this an item in tomorrows developer meeting, or have a chat after the meeting. A couple of things up front:
1. We should consider perhaps an integration with other WPS software that is out there (ie. 52North). Not sure if its feasible or not but we should at least get a decent idea of what else is out there.
2. I myself (and I know many others), will place a REST front end above a SOAP/WSDL front end. Theoretically we could have both but it might be nice to add REST to the picture.
Looking forward to chatting in the meeting.
-Justin
Jody Garnett wrote:
I am interested in doing some WPS 1.0 work (but no idea if I will get it). Talking on and off with Simone shows that a few other people are interested in working on WPS this year ...
As such I thought I would share some notes ...
- http://udig.refractions.net/confluence/display/HACK/WPSI would love to talk anyone interested after the GeoServer meeting tomorrow; or as the last topic in the meeting.
Jody
PS. I ended up using the uDig wiki since the geoserver wiki is in flux; and I am considering the end to end solution-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4007,47ccae8e100662143011171!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Justin Deoliveira wrote:
Hi Jody,
Sounds pretty darn exciting. WPS is something that has recently moved up my list of stuff I would like to see implemented. Chris and I chatted a bit about it this week.
I glanced over your notes, and yeah, for sure lets make this an item in tomorrows developer meeting, or have a chat after the meeting. A couple of things up front:
1. We should consider perhaps an integration with other WPS software that is out there (ie. 52North). Not sure if its feasible or not but we should at least get a decent idea of what else is out there.
Their client code is GPL and thus off limits for me. The have some interesting concepts; also you will be amused to review todays GeoTools meeting and Eclesia's propsoal. It seems that Eclisia / Jesse and myself came up with something at the GeoTools level that almost exactly lines up with WPS.
Note we are trying to stay more "direct"; an additional wrapper would be needed around a GeoTools Process in much the same way a FeatureTypeInfo is used to hold information about a FeatureSource.
The idea is we need Java developers to write these things at all; previous attempts failed by getting more complicated in several different directions.
2. I myself (and I know many others), will place a REST front end above a SOAP/WSDL front end. Theoretically we could have both but it might be nice to add REST to the picture.
I will add that to the list of considerations, my concerns are mostly around the handling of the SOAP / WSDL wrappers - but chances are that it is "easy" work that requires hard testing.
Looking forward to chatting in the meeting.
Jody
Justin Deoliveira ha scritto:
Hi Jody,
Sounds pretty darn exciting. WPS is something that has recently moved up my list of stuff I would like to see implemented. Chris and I chatted a bit about it this week.
Viva la WPS (revolution)!!!! 
I glanced over your notes, and yeah, for sure lets make this an item in tomorrows developer meeting, or have a chat after the meeting. A couple of things up front:
1. We should consider perhaps an integration with other WPS software that is out there (ie. 52North). Not sure if its feasible or not but we should at least get a decent idea of what else is out there.
Agreed. I guess there are a couple of problems:
* integrating with geoserver means using the dispatcher system, they
rolled their own alternative instead
* same goes for xml parsing, thought I cannot find the sources of
their model and parsing modules I kind of remember they used
xmlbeans (may be wrong, asking now)
* the interfaces they come up with are similar to the one we're trying
to define in gt2 (see Process proposal) but they are under the wrong
license for gt2.
Anyways, we should try to coordinate with them, they are using GT2 afaik. We may not be able to share code, but I fully agree with Justin, we should give it a try.
2. I myself (and I know many others), will place a REST front end above a SOAP/WSDL front end. Theoretically we could have both but it might be nice to add REST to the picture.
You mean, REST front end is more important than a SOAP one, right?
(first time I read it I understood something like building the REST
one on top of SOAP one, which does not seem to make sense to me...)
Looking forward to chatting in the meeting.
Me too!
Cheers
Andrea
You mean, REST front end is more important than a SOAP one, right?
(first time I read it I understood something like building the REST
one on top of SOAP one, which does not seem to make sense to me...)
Haha, nope, I meant the former.
Looking forward to chatting in the meeting.
Me too!
Cheers
Andrea!DSPAM:4007,47cd2112244235219720167!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Andrea Aime wrote:
Agreed. I guess there are a couple of problems:
* integrating with geoserver means using the dispatcher system, they rolled their own alternative instead
The fun part here for me is adding a SOAP/WSDL layer around the geoserver dispatcher system - anyone have an idea
how much work is involved on this one? I hope that REST could be treated the same way...
* same goes for xml parsing, thought I cannot find the sources of their model and parsing modules I kind of remember they used xmlbeans (may be wrong, asking now)
That would be good to know; I remember getting an invite to join a project that was jaxb bindings for all the OGC specifications (the code was all generated so it did not
really need to be open source; and the result looked horrible so I declined).
* the interfaces they come up with are similar to the one we're trying to define in gt2 (see Process proposal) but they are under the wrong license for gt2.
That reminds me; Simone was asking about associating ID and what not with a process; so we could support the various "Status" requests. This is the kind of thing
that should be coded up as a ProgressListener and injected into the execute( input, progress ) method - it is a completely orthogonal concern (that we should make
sure is accounted for).
It is going to be *very* tempting to complicate the GeoTools Progress proposal based on the need for WPS; if we possibly can I would like to keep things very simple
and lower the barrier to programming up a new Process.
Anyways, we should try to coordinate with them, they are using GT2 afaik. We may not be able to share code, but I fully agree with Justin, we should give it a try.
If you have a contact point please invite them to todays meeting.
2. I myself (and I know many others), will place a REST front end above a SOAP/WSDL front end. Theoretically we could have both but it might be nice to add REST to the picture.
You mean, REST front end is more important than a SOAP one, right? (first time I read it I understood something like building the REST one on top of SOAP one, which does not seem to make sense to me...)
That makes sense to me; the abstractions defined for SOAP are fine; it is the XML hell that is being objected to...
Looking forward to chatting in the meeting.
Me too!
Well lets make sure everyone has read the latest specification before we start; and if anyone has a contact that can supply the missing diagram links from appendix A I would love to look at the pictures.
Jody
Justin Deoliveira wrote:
You mean, REST front end is more important than a SOAP one, right?
(first time I read it I understood something like building the REST
one on top of SOAP one, which does not seem to make sense to me...)Haha, nope, I meant the former.
Since the SOAP wrapper just follows a recipe to convert the OGC messages to SOAP messages; could we just define a similar
convention for converting from OGC to REST (and skip out any SOAP induced madness that may complicate matters?). Basically
set SOAP / REST up as peers; both marshaling requests/response into the data model ...
Looking forward to chatting in the meeting.
I am going to go back to reading,
Jody
I see what your getting at... but not sure it makes sense for REST. The SOAP and OGC interfaces are similar enough to do this.. but rest is a much different paradigm. I think it makes sense to just implement REST "bindings" directly, instead of generating them from an OGC interface specification.
2c.
-Justin
Jody Garnett wrote:
Justin Deoliveira wrote:
You mean, REST front end is more important than a SOAP one, right?
(first time I read it I understood something like building the REST
one on top of SOAP one, which does not seem to make sense to me...)Haha, nope, I meant the former.
Since the SOAP wrapper just follows a recipe to convert the OGC messages to SOAP messages; could we just define a similar
convention for converting from OGC to REST (and skip out any SOAP induced madness that may complicate matters?). Basically
set SOAP / REST up as peers; both marshaling requests/response into the data model ...Looking forward to chatting in the meeting.
I am going to go back to reading,
Jody-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4007,47cd911a113741439371379!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Justin Deoliveira wrote:
I see what your getting at... but not sure it makes sense for REST. The SOAP and OGC interfaces are similar enough to do this.. but rest is a much different paradigm. I think it makes sense to just implement REST "bindings" directly, instead of generating them from an OGC interface specification.
Good; that is what I was trying to say - implement REST Directly (don't complicate matters with a REST / SOAP bridge). Do you actually need to define seperate data structures / concepts for REST to work?
Jody
