On Tue, Jan 22, 2013 at 12:57 PM, Chris Holmes <chol...@opengeo.org> wrote:
> Cool, makes good sense, and was about what I suspected, was just curious
> for the full articulation. Thanks Andrea.
>
> Might be good at some point to lay out this policy explicitly. But to not
> over complicate things we can just refer to this thread if it comes up.
>
Seems a little extreme to be making changes to project policy in response
to proposals that weren't made. But I guess it is better than waiting
until the issue comes up (and confusing policy with the decision made for a
specific case.)
On Mon, Jan 21, 2013 at 10:41 AM, Justin Deoliveira <jdeol...@opengeo.org>wrote:
>
>> Nothing to add here except that i agree that it should be only pure java
>> in the core of GeoTools and GeoServer. Plugins and community modules I
>> could perhaps see an argument for if the module has a stable maintainer.
>>
>
Well, plugins are currently clear to my knowledge, but GeoServer already
has a community module which is written in a non-Java language - the CSS
module which I maintain. This has been written in Scala since its
inception over two years ago (although I rewrote most of the frontend in
Java at Andrea's request about a year ago.) Is it acceptable for a
community module to depend on a runtime library like Scala's? What about
having Scala code outright?
The CSS module originally lived outside of the GeoServer repository so I
don't guess it would be a problem to go back.
--
David Winslow
OpenGeo - http://opengeo.org/
On Thu, Jan 17, 2013 at 9:55 AM, Andrea Aime
<andrea.a...@geo-solutions.it>wrote:
>>
>>> Chris holmes wrote:
>>> >Out of curiosity, why is this so bad? I mean it complies to pure java
>>> bytecode, could just be thought of an
>>> > additional library, like the xml stuff we do. It'll interoperate on
>>> any platform, which to me was the big
>>> > downside in bringing in other languages.
>>>
>>> There is a variety of issues why I believe we should be firm about never
>>> including another JVM language in core (unless.. read towards the end).
>>>
>>> The nice thing about having scripting languages as an extension is that
>>> everybody can pick their preferred scripting language and go down writing
>>> their cool extension. Someone goes with Jython, another one has a
>>> preference for Scale, someone else is a Groovy type, the other guy over
>>> there is a JRuby kind of person, and yet everybody is happily writing their
>>> own thing. Tomorrow someone comes and wants to use Ceylon, or Kotlin, or
>>> Clojure, and by using the JSR for scripting languages we can slot in those
>>> as well.
>>> This is splendid... as long as we think in terms of custom extensions
>>> that are not shared with a larger community.
>>>
>>> Now let's ramp up a bit, and let's say people start writing official
>>> extensions in non Java languages.
>>> You just download them and add them to your GeoServer, everything is
>>> working, it's all fine, right?
>>> Nope, whilst it's not too bad, it's not fine either:
>>> - each scripting language comes with its own runtime library, which is
>>> often rather heavy (several megabytes) pushing on our already quite
>>> poor permgen situation. And then... what if I need two or three of these
>>> extensions, all needing their own different runtime? That just multiplies
>>> the problem
>>> - "polyglot" programmers are not the norm today, and even those that are
>>> polyglots have made choices,
>>> creating a partitioning of the potential programmer base in tiny
>>> pieces, just see GeoScript, how many
>>> people are there developing for a single language? GeoScript might
>>> have five developers, but
>>> GeoScript Python or GeoScript Scala really have one, they are one man
>>> projects at the moment (scary).
>>> Add to that the GIS nature of the project, and the set of developers
>>> that can do GIS in a certain non
>>> Java language becomes a niche within a niche
>>> It means that a module written in a language other than java has a
>>> much higher likeliness to just die
>>> if the developer working on it leaves
>>>
>>> Now, let's ramp up another bit and consider a core in which non Java
>>> languages are allowed.
>>> The permgen issue would just happen all the time, and some parts of the
>>> code would be limited
>>> to a single person, when that one leaves you'll have two high leaning
>>> curves to go after,
>>> first learning a new language, and then learning about whatever the code
>>> there is doing.
>>> Moreover, code in "core" is officially maintained "by the PSC", which is
>>> good, it means a group
>>> of people care about that code. But in a multi-language scenario, that's
>>> not possible anymores
>>> unless the PSC members also become "language geeks".
>>>
>>> That's why I believe that while extensions written in a non Java
>>> language are sort of ok
>>> (but they will be troublesome the day we have many), core in non Java
>>> language is simply
>>> not an option.
>>>
>>> Unless... well, unless the non Java language war starting during these
>>> years ends with a clear
>>> winner, a new languages that really takes the place of Java obliterating
>>> all of the other
>>> competitors.
>>> If in a future Scala becomes the de facto non Java choice, and Jython,
>>> JRuby, Groovy, Clojure, Kotlin, Ceylon
>>> (and all the others that I won't list) get relegated to a very small
>>> percentange, well, in that case I'll be very happy
>>> to switch the entire project to Scala
>>>
>>> Cheers
>>> Andrea
>>>
>>>
>>>
>>> --
>>> ==
>>> Our support, Your Success! Visit 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
>>>
>>> -------------------------------------------------------
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
>>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
>>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
>>> MVPs and experts. ON SALE this month only -- learn more at:
>>> http://p.sf.net/sfu/learnmore_122712
>>> _______________________________________________
>>> Geoserver-devel mailing list
>>> 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.
>>
>>
>> ------------------------------------------------------------------------------
>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
>> MVPs and experts. SALE $99.99 this month only -- learn more at:
>> http://p.sf.net/sfu/learnmore_122412
>>
>> _______________________________________________
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnnow-d2d
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
