On Fri, May 31, 2013 at 3:10 PM, David Winslow <[email protected]> wrote:
> On Andrea's notes about extensions, I think that if a client wants to use
> a module but can't because their policy is not to use extensions, that's
> not a very good reason to bring the extension into core. Maybe we should
> be investigating how to overcome this perception that extensions are not
> well supported (they are endorsed by the project, right?)
>
Given the rules for promoting a module to extension, I cannot really say
"they are endorsed by the project", three users, enough unit testing, one
maintainer, considere "stable" by the PSC:
http://docs.geoserver.org/stable/en/developer/policies/community-modules.html#promoting-a-community-module
Anyone can get a module in extension by following those rules, regardless
of whether the PSC thinks the module is important, useless, annoying, or
trivial, provided it cannot be argued that it's not stable.
If the maintainer drops, so goes the module.
My perception of community space is different than Justin's one, community
space is either nursery, dumpster or limbo, a fresh module is nursery for
sure, the others... well...
It also matches well how people can access the modules in community, only
by nightly builds, which means only people interested in "playing" with
them and enough technically skilled to use them (provided they are getting
in the community release at all).
Extension modules are tight and clean, but they are not in core because
they are either not popular enough or problematic in some way. And they are
still normally managed by a single dev (app-schema and to a lesser extent
WPS are the notable exceptions I believe). And I believe it's fine like
this, it is and should stay easy to get into extension, since only there
you start getting real usage by the user base beyond enthusiasts.
By they still are lights year away from a core module in terms of user base
usage and support. To give you a simple example, think the Oracle module.
Important? Well, I'd say very. Supported as well as PostGIS which is
available right in core? We had to squash 90% of their code base to avoid
Oracle drifting away, and despite it PostGIS still works better.
Now compare with something minor like "querylayer". It is still an
extension module, it is still supported. Comparable to a core module? Nah.
Comparable to a module like WPS or Oracle in usage and support term? Not a
chance either.
Just being in extension is a guarantee, docs, tests, maintainer, but does
not come even close to being in core, there is actually a lot of
variability among the extension modules.
> Or maybe a technical solution would be to add some extension management
> facilities (enabling/disabling, graphically installing, etc) in order to
> make it easier to reduce the PermGen and other impacts of GeoServer's
> growing core.
>
Yes, this would be great :-)
I'm afraid we'd have to give up the simple spring oriented pluggability and
start looking into something like OSGI to get there. Tall order...
Cheers
Andrea
--
==
GeoServer training in Milan, 6th & 7th June 2013! Visit
http://geoserver.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
-------------------------------------------------------
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
