[17:03] -barjavel.freenode.net- * Looking up your hostname...
[17:03] -barjavel.freenode.net- * Checking Ident
[17:03] -barjavel.freenode.net- * Couldn't look up your hostname
[17:03] -barjavel.freenode.net- * No Ident response
[17:03] * LogBot_52n (~PircBot@188.8.131.52) has joined #52north
[17:03] * Topic is '52°North Discussion Group | Geospatial Open Source Software, geo-hacking, lunch planning. | About this channel: http://wiki.52north.org/bin/view/Documentation/IRC'
[17:03] * Set by daniel_52n!~Daniel@184.108.40.206 on Mon Nov 18 18:06:46 CET 2013
[17:03] * bot_52n sets mode +o LogBot_52n
[17:03] * daniel_52n_ is now known as daniel_52n
[17:04] * auti is now known as autermann_52n
[17:05] <daniel_52n> ok, so maybe we can start by giving a quick introduction why autermann_52n is with us today :-)
[17:06] <daniel_52n> when we thought about GSoC 2014 we realized that we did not yet integrate a very useful devlopment from last years GSoC:
[17:06] <daniel_52n> the admin interface
[17:07] <daniel_52n> Christian started again as a software developer and we grabbed him before he could get any other tasks to do it :-)
[17:07] <daniel_52n> looking at the source code it soon became clear that there is no easy way to integrate the admin interface into the current WPS
[17:07] <daniel_52n> the main issue here is the very "static" configuration
[17:08] <daniel_52n> IvanSuftin-CIDA: do you rely on the existing configuration (WPSConfig) ?
[17:09] <daniel_52n> so our thinking then went like this: if we need to do a lot of refactoring to integrate the admin interface...
[17:10] <daniel_52n> then we should overhaul the complete configuration method.
[17:10] <IvanSuftin-CIDA> daniel_52n: we do, yes.
[17:11] <daniel_52n> ok.
[17:12] <daniel_52n> the goal of the admin interface is of course to allow configuration of all the different backends, and to be more flexible when building the WPS - e.g. build a WPS only with the R or only the GRASS backend.
[17:12] <daniel_52n> IvanSuftin-CIDA: if I remember correctly, you also have a specific mechanism to build and deploy your WPSs ?
[17:12] <IvanSuftin-CIDA> ill the admin interface be a ui on top of a set of (RESTful?) services?
[17:13] <daniel_52n> the current GSoC implementation not, just uses spring
[17:14] <daniel_52n> our first approach would be to leave that as it is.
[17:15] <autermann_52n> we want to try to change the WPS API so that we can use any configuration API we want, the GSOC one, programmatic configuration, and may be a new REST API.
[17:16] <autermann_52n> changing the current GSOC implementation to use a REST API would need more effort than just implement a seperate API at some point
[17:18] <daniel_52n> in any case, the changes to configuration API require to make a change in the major release.
[17:18] <daniel_52n> realizing that, we said that it would be a good situation to completely overhaul the WPS module structure.
[17:19] <daniel_52n> so, Christian is basically trying to sketch such a structure and to find out how a "WPS 4" could look like.
[17:19] <daniel_52n> an that is why we wanted to get your (CIDA
[17:19] <daniel_52n> 's) opinion on this and learn how such changes would affect your usage of the WPS.
[17:20] <daniel_52n> (btw I'm just the fastest typer here, benjamin_52n is still on board )
[17:21] <daniel_52n> oh, yes, and one more very important side-effect: we can split out the processing backends which is very important right now because of the dependency on geotools
[17:22] <IvanSuftin-CIDA> How would the admin interface change the use of the wps_config.xml? Would that be writing to that file or...?
[17:22] <daniel_52n> geotools uses a library under EPL which is, based on our latest research, not compatible with GPL... this is a MAJOR issue.
[17:23] <daniel_52n> (this interpretation of license compatibility might not apply under US law...)
[17:24] <IvanSuftin-CIDA> We use geotools pretty heavily both as a dependency in other applications (52N-WPS, Geoserver, etc) as well as using it directly
[17:24] <IvanSuftin-CIDA> And for US gov that is an issue
[17:24] <autermann_52n> the core should no more have a single persistence strategy for the config. The admin interface uses a HSQDB but we will plan to allow other backends such as the wps_config.xml based approach (or even no presistent backend but a hard coded programmatic approach)
[17:25] <IvanSuftin-CIDA> Yes, using a SQL db for configuration would be great
[17:25] <daniel_52n> so you came across that EPL dependency before?
[17:25] <autermann_52n> you still can use geotools, but the core WPS modules won't offer it anymore. you would probably rely on a dependency liek 52n-wps-geotools which packages the parsers and generators
[17:26] <daniel_52n> and 52n-wps-geotools might have to become a seperate repository, to be safe regarding the licenses.
[17:29] <daniel_52n> we're just checking the Geoserver license - their license terms as an exclusion for EPL it seems
[17:29] <daniel_52n> so the license argument might not be as pressing as I said before (IF we change the license header)
[17:29] <IvanSuftin-CIDA> daniel_52n: We've not dealt with geotools licensing issues previously
[17:29] <daniel_52n> ok
[17:30] <daniel_52n> BUT even without the license issue the modularization is imho worth the effort
[17:30] <IvanSuftin-CIDA> I agree. This is actually interesting. Its the first I've heard about Geotools being EPL
[17:31] <IvanSuftin-CIDA> Do you know which library it is?
[17:32] <daniel_52n> one for XML Schema Definition
[17:32] <daniel_52n> it is actually mentioned in the GeoServer license exception: http://geoserver.org/display/GEOS/License
[17:36] <IvanSuftin-CIDA> Interesting. So yeah, I would agree that modularizing the functionality depending on that lib to a different maven module would be a step in the right direction
[17:38] <daniel_52n> ok. so the BIG question:
[17:39] <daniel_52n> how much work would it be for you to change to WPS 4?
[17:40] <daniel_52n> that's the reason why christian is currently trying to refactor the WPS and get the admin interface working
[17:40] <daniel_52n> then we'll have a new project structure to discuss.
[17:40] <IvanSuftin-CIDA> I couldn't say. I'm unsure of what changes would be required of us. We'd have to play with it to really know
[17:41] <daniel_52n> right. so our resources are currently used for this.
[17:41] <daniel_52n> I think it is also a very good step for support of many of the long term goals (on the Trello board), since we will be able to work on independent parts of the WPS.
[17:42] <daniel_52n> IvanSuftin-CIDA: we just want to get the process started and we'll let you know as soon as there is something to play around with.
[17:43] <daniel_52n> IvanSuftin-CIDA: how many WPS do you actually have deployed?
[17:44] <IvanSuftin-CIDA> I want to say in production we have about 4 or 5
[17:45] <daniel_52n> ok. so our goal would of course be to make an update of your services as easy as possible so that we're not working on 3.x and 4 in parallel in two years time.
[17:47] <IvanSuftin-CIDA> Do you plan on deprecating 3.x branch as soon as 4 is released?
[17:49] <daniel_52n> we're not sure how hard it is to stay downwards compatible
[17:49] <daniel_52n> things like a Java algorithm, R scripts would be transferable without changes
[17:50] <daniel_52n> encoder and decoder not so much since the interface will change
[17:51] <daniel_52n> and "we" as in 52N cannot afford to provide long term support.
[17:52] <daniel_52n> but "we" as in community: such a question is the reason we're having these meetings with you guys :-)
[17:54] <IvanSuftin-CIDA> Understood. I haven't kept up ith the email list lately but has that question been posed to the list?
[17:54] <daniel_52n> no, not yet.
[17:56] <daniel_52n> we want to get an idea about what the changes in the internal API would actually be
[17:56] <daniel_52n> but you're right, at least the -dev list should be included now.
[17:57] <daniel_52n> we also have a Trello board to organize our "exploration"
[17:57] <daniel_52n> and that's really what it is so far.
[18:00] <IvanSuftin-CIDA> I think on our end we'd end up using 4 on new projects with no pain and then go through upgrading 3.x to 4 on older projects when we have work on them so that would be part of the work plan for any upcoming work
[18:01] <daniel_52n> that's great.
[18:01] <benjamin_52n> Sounds like a plan
[18:01] <daniel_52n> and this upgrade process might actually not be that bad - we're just cautious I guess.
[18:02] <daniel_52n> I added you to the trello board so you can keep an eye on the progress.
[18:02] <daniel_52n> benjamin will sent out the meeting minutes, too.
[18:03] <IvanSuftin-CIDA> Great!
[18:03] <daniel_52n> and of course everybody is invited to give feedback.
[18:03] <IvanSuftin-CIDA> Have you guys tried out the Trello mobile app? Everyone here seems to love it
[18:03] <daniel_52n> no, I haven't - is it for free?
[18:03] <IvanSuftin-CIDA> Yes
[18:03] <daniel_52n> will do :-)
[18:04] <daniel_52n> so, we suggest to skip next mondays meeting and on the next monday...
[18:05] <IvanSuftin-CIDA> So no meeting for 2 weeks or just next monday?
[18:05] <daniel_52n> we'll take a look at the long-term goals again, or hopefully autermann_52n can present the current state of refactoring.
[18:06] <daniel_52n> we'll skip coming monday, meet again on the monday after sleeping 10 times.
[18:06] <IvanSuftin-CIDA> Okay that sounds fine
[18:06] <benjamin_52n> i will send a reminder :)
[18:10] <daniel_52n> gotta go, bye!
[18:10] <IvanSuftin-CIDA> Talk to you guys later!
[18:10] * IvanSuftin-CIDA (email@example.com) Quit (Quit: leaving)
[18:15] * daniel_52n (~Daniel@220.127.116.11) Quit (Ping timeout: 265 seconds)
Topic revision: r1 - 07 Feb 2014, BenjaminPross