I'm ignoring the extension API problem for now. I've submitted a pull request containing our code as a community module:
I would prefer just to make an interface in the GeoServer source tree and be done with it, but that code would fall under the GPL license just by being placed in the GeoServer source tree, according to Andrea. Since implementors don't need to make use of any GeoServer classes, this is unnecessarily restrictive. Unless it's not the case that the interface has to be GPL...
Yep, Guava has what we need; no need to bring in another Functor. The only thing that bugs me is the lack of generic tuples; right now we can express F:A->B but can't express F:A->B->C, for example, and just have to rely on arrays or special-case structs for functions that take multiple arguments. (There might already be a tuple on the classpath; I just can't find any.)
------------------------------------------------------------------------
*From:* Jody Garnett <jody.garnett@anonymised.com>
*Sent:* Sunday, September 15, 2013 10:48 PM
*To:* Justin Deoliveira
*Cc:* Dustin Parker; Andrea Aime; geoserver-devel@lists.sourceforge.net; Dale F. McIntosh
*Subject:* Re: [Geoserver-devel] GeoServer notification plugin
It is not really that murky, any of our GeoServer plugins tend to implement a GeoServer interface of some sort ... thus making it very clear that they need to be GPL. They require some GPL code in order to compile.
The exception is plugins that implement a GeoTools interface, such as a DataStore. These only depend on LGPL which places fewer restrictions on the result code.
Indeed a mix of these two approaches is possible (and recommended). You will see a number of ideas that have a datastore or raster format in GeoTools, backed up by a GeoServer community module donating addition user interface code.
I do not think we make use of the GPL classpath exception license (indeed since GeoServer is GPL we do not require the classpath exception for our application to be run on the JVM).
Jody
On Mon, Sep 16, 2013 at 12:16 AM, Justin Deoliveira <jdeolive@anonymised.com <mailto:jdeolive@anonymised.com>> wrote:
Hey Dustin,
I generally suggest that people try to avoid extra dependencies if
not needed, especially in core modules. However given that this is
itself a plugin I don't think that is a show stopper. Although
there does seem to be overlap with the commons functor library and
the guava library that we already depend on.
That said, I wonder why not just make NotificationSink an
interface or abstract class? And then allow folks to provide
implementations via spring contexts. This would more follow the
typical geoserver extension point architecture.
Regarding the licensing of classes provided by a plugin via
spring, it is unfortunately murky waters. As I understand it the
"gpl classpath exception" allows one to license plug-ins
differently than the core of GeoServer. Unfortunately it is
something that isn't really well understood in my experience which
hinders its usefulness. Jody actually knows much more about it and
can provide some guidance.
-Justin
On Thu, Sep 12, 2013 at 5:23 PM, Dustin Parker
<dparker@anonymised.com <mailto:dparker@anonymised.com>> wrote:
Okay, forget the public API part. How about this hypothetical API:
1. There's a bean type (call it NotificationSink) in the
wfs-notification plugin that is used to dispatch
notifications. Users create more of these by dropping its name
into their own applicationContext.xml, but they don't need to
bind to it in their own Java code.
2. NotificationSink can take one or two functors:
* A mandatory function that takes a String (or byte?)
that represents a serialized message
* An optional predicate that returns boolean to indicate
whether or not the sink is ready to receive input
3. Those functors can refer to a specific instance of a class
by being non-static inner classes themselves.
4. Spring can inject those functors into a NotificationSink by
way of an instance factory. (Make a specialized notification
class and provide getters that return functors.)
I'm not married to the details at this point, just trying to
determine feasibility.
Apache Commons Functor provides a set of interfaces that could
be used, so that would be an extra dependency.
With that in mind, if a Spring configuration file names a
class licensed under the GPL, does that make the Spring config
class a "derivative work" for the purposes of the GPL?
-- Dustin Parker - Forward Slope, Inc.
Cell: 619 277 2591 <tel:619%20277%202591>
SYBWB UI EXCEFI EK BEIF IRXMSURK SR BTBWF YMHEK
OWRZXBH--KBES, OXEMIUZXB, EKD CWRKV. - Y. X. HBKNABK
H4sIAOlx7FACA02MuQ7CMBQEe3/FdjTgcIWrSUMBFQVI1A5+2BaJ
HcUPTP6eU4J2dmb37o49K0MR4Yw1lVdjnDdiJHGwinFSvsewqmnI
SzH+Uh0o/jiCR92hVifrPEkx+VrRhmul//upxNF27xz8Uj5DIXKJ
ne1ji0jPg5nEJiRopz8W3ahFCu2lEHOJePMoK1WTWDwrT9CqQyIk
V1VIrWMCU+QoBrDMzSrLShWtDK3JimU+zBcj8QDNJmEc9gAAAA==
On 2013-09-06 23:04, Andrea Aime wrote:
On Fri, Sep 6, 2013 at 8:16 PM, Dustin Parker
<dparker@anonymised.com
<mailto:dparker@anonymised.com>
<mailto:dparker@anonymised.com
<mailto:dparker@anonymised.com>>> wrote:
By the way, I forked/branched and made it an actual
community module:
https://github.com/dustinparker/geoserver/tree/wfs-notification
<https://github.com/dustinparker/geoserver/tree/wfs-notification>
In src/community/wfs-notification there are two
sub-modules: the
plugin itself and an API. I want to release the plugin
has to be
GPL because it binds to GPL'd code, but I want the API
to be LGPL
and only use GeoTools. This will make it much easier
from a
licensing perspective for others to add any new messaging
providers they may need. Do y'all have any thoughts on
that? Is
this approach even kosher, or do I need to publish the
API outside
and somehow get it into a public repository?
No code in the GeoServer repository can be GPL'd, the
license at the top of the source tree applies
to the whole tree as far as I remember.
Either you contribute that API to GeoTools (and it has to
make sense as a first class component of it),
or you build a separate project containing the API, and
have your GeoServer plugin (GPL'd) depend on it.
Generally speaking to dodge the GPL you have to set it up
so that whatever you're writing makes sense
without any GeoServer environment around it, the moment
you use even one bit of GeoServer you're
back to GPL.
Cheers
Andrea
-- ==
Our support, Your Success! Visit
http://opensdi.geo-solutions.it
<http://opensdi.geo-solutions.it> for more information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313 <tel:%2B39%200584%20962313>
fax: +39 0584 1660272 <tel:%2B39%200584%201660272>
mob: +39 339 8844549 <tel:%2B39%20%20339%208844549>
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record
for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual,
redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
<mailto:Geoserver-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
-- Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
