[Geoserver-devel] Scripting WPS processes (and functions) in any scripting language out of the box

Hi,
I was wondering, did anyone in the scripting real consider using the JSR 223
extensions to have GeoServer processes and functions be scriptable in
any JVM supported language?

The scripting support seems rather simple to use:
http://java.sun.com/developer/technicalArticles/J2SE/Desktop/scripting/

What I was thinking is something along the line of having two files for each
process, a description one, and a script one.
The description one would be uniform for all processes/functions, and would
indicate what scripting engine to use. Something like:

{
    engine: rhino,
    title: "Centroid Example",
    description: "Example script that calculates the centroids of the
input geometries",
    inputs: {
        features: geotools.feature.FeatureCollection
    },
    outputs: {
        centroid: geotools.feature.FeatureCollection
    }
}
The second one instead would be a pure script, which we'd pass parameter to
using the JSR 223 script context.

The efforts I see so far are focused on a specific language, meaning that if
I wanted to script something using beansheel or jruby I'd have to build some
custom support. With a generic JSR 223 support we'd have the ability to
use any language instead, maybe adding some generic java sugar to invoke
other processes (I see process orchestration as the sweet spot for scripting
languages).

Another idea would be to actually add a level of indirection and make our own
engine interfaces, with one implementation able to relay to any JSR
223 scripting
language in the classpath.
But other engines could for example wrap geoscript and eventually
perform initializations
and/or data transformation before calling the process (such as
wrapping feature collections
in their own wrappers).
Another interesting use case could be a "command line" scription
enginge, allowing to call
onto any shell program (this one would make for a nice built-in
scripting engine).

Ah, what about functions? The process/function bridge in the geotools
gt-process module
re-registers any process with just one output as a function.
This is done to support rendering transformations, but it also means
that one can write
processes and functions as if they were the same thing.

Opinions?

Cheers
Andrea

PS: all of this started with me wanting to use beanshell to create a
chain of processes
with a sprinkle of orchestration logic added. I wanted a script
language that I could
learn in a hour, with a very small jar, and with no extra deps, and
beanshell fit the bill nicely.

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

Yeah I think the scripting jsr is pretty promising and potentially have one scripting extension to rule them all. Or at least one core extension to define the scripting hooks and the like with some extensions for each language.

One of the problems for jython last time I checked wad that here was only support for jython 2.2 which is pretty old at this point. But I really need to check back.

But yeah a good exercise would be to take the python community module and try to replace it with code that works solely against jsr 223.

On Aug 19, 2011, at 8:01 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
I was wondering, did anyone in the scripting real consider using the JSR 223
extensions to have GeoServer processes and functions be scriptable in
any JVM supported language?

The scripting support seems rather simple to use:
http://java.sun.com/developer/technicalArticles/J2SE/Desktop/scripting/

What I was thinking is something along the line of having two files for each
process, a description one, and a script one.
The description one would be uniform for all processes/functions, and would
indicate what scripting engine to use. Something like:

{
   engine: rhino,
   title: "Centroid Example",
   description: "Example script that calculates the centroids of the
input geometries",
   inputs: {
       features: geotools.feature.FeatureCollection
   },
   outputs: {
       centroid: geotools.feature.FeatureCollection
   }
}
The second one instead would be a pure script, which we'd pass parameter to
using the JSR 223 script context.

The efforts I see so far are focused on a specific language, meaning that if
I wanted to script something using beansheel or jruby I'd have to build some
custom support. With a generic JSR 223 support we'd have the ability to
use any language instead, maybe adding some generic java sugar to invoke
other processes (I see process orchestration as the sweet spot for scripting
languages).

Another idea would be to actually add a level of indirection and make our own
engine interfaces, with one implementation able to relay to any JSR
223 scripting
language in the classpath.
But other engines could for example wrap geoscript and eventually
perform initializations
and/or data transformation before calling the process (such as
wrapping feature collections
in their own wrappers).
Another interesting use case could be a "command line" scription
enginge, allowing to call
onto any shell program (this one would make for a nice built-in
scripting engine).

Ah, what about functions? The process/function bridge in the geotools
gt-process module
re-registers any process with just one output as a function.
This is done to support rendering transformations, but it also means
that one can write
processes and functions as if they were the same thing.

Opinions?

Cheers
Andrea

PS: all of this started with me wanting to use beanshell to create a
chain of processes
with a sprinkle of orchestration logic added. I wanted a script
language that I could
learn in a hour, with a very small jar, and with no extra deps, and
beanshell fit the bill nicely.

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

On Fri, Aug 19, 2011 at 11:14 PM, Justin Deoliveira
<jdeolive@anonymised.com> wrote:

Yeah I think the scripting jsr is pretty promising and potentially have one scripting extension to rule them all. Or at least one core extension to define the scripting hooks and the like with some extensions for each language.

One of the problems for jython last time I checked wad that here was only support for jython 2.2 which is pretty old at this point. But I really need to check back.

It seems we're up to 2.5.1 now:
http://wiki.python.org/jython/UserGuide#using-jsr-223

But yeah a good exercise would be to take the python community module and try to replace it with code that works solely against jsr 223.

My python fu is not good, but I may try porting something simple.
What about adding a new community module, scripting, that can be used
as a playground
for the API and see if we can have some working examples of python,
javascript, beanshell
and maybe bourne shell going

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

On Sat, Aug 20, 2011 at 12:52 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Fri, Aug 19, 2011 at 11:14 PM, Justin Deoliveira
<jdeolive@anonymised.com> wrote:

Yeah I think the scripting jsr is pretty promising and potentially have one scripting extension to rule them all. Or at least one core extension to define the scripting hooks and the like with some extensions for each language.

One of the problems for jython last time I checked wad that here was only support for jython 2.2 which is pretty old at this point. But I really need to check back.

It seems we’re up to 2.5.1 now:
http://wiki.python.org/jython/UserGuide#using-jsr-223

Nice!

But yeah a good exercise would be to take the python community module and try to replace it with code that works solely against jsr 223.

My python fu is not good, but I may try porting something simple.
What about adding a new community module, scripting, that can be used
as a playground
for the API and see if we can have some working examples of python,
javascript, beanshell
and maybe bourne shell going

Well most of the code in the python module is just straight java stuff that adapts the scripting engine into the various extension points. +1 on a community module to start experimenting with straight jsr-223. We can start with one of the straight forward extension points and see how that works.

Cheers
Andrea

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf



Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.