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 <[email protected]>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
>
> SYBWB UI EXCEFI EK BEIF IRXMSURK SR BTBWF YMHEK
> OWRZXBH--KBES, OXEMIUZXB, EKD CWRKV. - Y. X. HBKNABK
>
> H4sIAOlx7FACA02MuQ7CMBQEe3/**FdjTgcIWrSUMBFQVI1A5+2BaJ
> HcUPTP6eU4J2dmb37o49K0MR4Yw1lV**djnDdiJHGwinFSvsewqmnI
> SzH+Uh0o/jiCR92hVifrPEkx+**VrRhmul//upxNF27xz8Uj5DIXKJ
> ne1ji0jPg5nEJiRopz8W3ahFCu2lEH**OJePMoK1WTWDwrT9CqQyIk
> V1VIrWMCU+**QoBrDMzSrLShWtDK3JimU+**zBcj8QDNJmEc9gAAAA==
>
> On 2013-09-06 23:04, Andrea Aime wrote:
>
>> On Fri, Sep 6, 2013 at 8:16 PM, Dustin Parker 
>> <[email protected]<mailto:
>> dparker@forwardslope.**com <[email protected]>>> 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
>> fax: +39 0584 1660272
>> mob: +39 339 8844549
>>
>> http://www.geo-solutions.it
>> http://twitter.com/**geosolutions_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
> [email protected]
> 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/22/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Reply via email to