Hi,
I'd like to propose the removal of GML and VPF extensions
from the GeoServer downloads. The rationale is as follows:
- afaik, they do not work properly (for sure the GML one
does not)
- the datastores have been un-maintained for a long time
- we cannot really provide any decent support on them
- they have been there for years already in that state,
and no one from outside the project stepped up to
actually provide maintenance
I guess we should point people to ogr2ogr as a tool
to convert both formats into something (shapefile, postgis)
that can actually be used for efficient web serving.
Opinions?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Works for me. But outright removing them seems a bit harsh. It might be good to poll the users list first to ensure that indeed noone depends on them, since it is not that much of a hassle to have them around and tell people they are unsupported imho.
Andrea Aime wrote:
Hi,
I'd like to propose the removal of GML and VPF extensions
from the GeoServer downloads. The rationale is as follows:
- afaik, they do not work properly (for sure the GML one
does not)
- the datastores have been un-maintained for a long time
- we cannot really provide any decent support on them
- they have been there for years already in that state,
and no one from outside the project stepped up to
actually provide maintenance
I guess we should point people to ogr2ogr as a tool
to convert both formats into something (shapefile, postgis)
that can actually be used for efficient web serving.
Opinions?
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Justin Deoliveira ha scritto:
Works for me. But outright removing them seems a bit harsh. It might be good to poll the users list first to ensure that indeed noone depends on them, since it is not that much of a hassle to have them around and tell people they are unsupported imho.
I'm not much worried about the hassle per se, but the bad
image it gives us, first we list a functionality, when
people try to use it, it does not work at all and we
provide no support other than saying "yeah, it does not
work, it's not supported either".
A poll works for me. Anyone else wants to share an opinion
on this?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
According to SourceForge, people are definitely downloading both extensions [1]. Not many, but > 0. So we should definitely let people know that we may be pulling the rug out from under them and see how loudly they protest.
Is it worth it to continue to publish the extensions with a large red warning label on them?
[1] http://sourceforge.net/project/showfiles.php?group_id=25086&package_id=129885
Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Works for me. But outright removing them seems a bit harsh. It might be good to poll the users list first to ensure that indeed noone depends on them, since it is not that much of a hassle to have them around and tell people they are unsupported imho.
I'm not much worried about the hassle per se, but the bad
image it gives us, first we list a functionality, when
people try to use it, it does not work at all and we
provide no support other than saying "yeah, it does not
work, it's not supported either".
A poll works for me. Anyone else wants to share an opinion
on this?
Cheers
Andrea
hello all,
apologies for the intrusion on the list but may i suggest an alternative
to simply removing those extensions which could be a potential source of
funding for the GeoServer developers: grade the extensions, say into
three levels of quality (high, medium, and low) and continue publishing
them. users can then judge for themselves and would know what to expect
if they find a bug. this of course depends on a minimal level of
functionalities these extensions should have --beyong getting compiled
without errors 
later on, and on regular basis you could study the download figures and
a decision to retire or change the grade of extensions can be made.
On Thursday 19 March 2009 19:53:11 Andrea Aime wrote:
Hi,
I'd like to propose the removal of GML and VPF extensions
from the GeoServer downloads. The rationale is as follows:
- afaik, they do not work properly (for sure the GML one
does not)
- the datastores have been un-maintained for a long time
- we cannot really provide any decent support on them
- they have been there for years already in that state,
and no one from outside the project stepped up to
actually provide maintenance
I guess we should point people to ogr2ogr as a tool
to convert both formats into something (shapefile, postgis)
that can actually be used for efficient web serving.
Opinions?
Cheers
Andrea
cheers;
rsn
Raif S. Naffah ha scritto:
hello all,
apologies for the intrusion on the list but may i suggest an alternative to simply removing those extensions which could be a potential source of funding for the GeoServer developers: grade the extensions, say into three levels of quality (high, medium, and low) and continue publishing them. users can then judge for themselves and would know what to expect if they find a bug. this of course depends on a minimal level of functionalities these extensions should have --beyong getting compiled without errors
later on, and on regular basis you could study the download figures and a decision to retire or change the grade of extensions can be made.
Mumble, what would the criteria be? Atm we have the following:
- whatever is in the core distribution is actually supported
and used by the developers
- real GeoServer extensions (i.e., imagemap, excel) have support, they
are just not considered of general interest enough to be part of the
core distribution but they could be considered high quality
- a number of data/coverage store (oracle I'm looking at you) extensions
may have a maintainer but the level of support on them is definitely
lower (medium)
- certain extensions are not really working, and we know it. We could
say they are "low" quality, but it's kind of a stretch since we all
know they have no maintainer at all -> support level on them is zero
solid. If you want to actually use them, better be a developer that
can fix any issue that might come up.
I have troubles going out and tell the world "here, this is not working
and we know it". I mean, by the same token we could start adding
other stuff that's sitting in GT2 as well no? Looking into
geotools unsupported we have netcdf, geomedia, gpx, geometryless,
sql-datastore, tiger that are in no real better shape of the gml
datastore. Maybe they work, maybe they don't, no core dev really
knows any better than that (I never tried out the gml/vpf datastores
for example).
Afaik the idea behind providing gml2 datastore was around the lines
of "let's see if anybody is interested enough to step up and become
maintainer of that stuff".
A more serious approach, imho, could be to list all of these and point
people to the sources: "Interested? Jump on the dev board and help
us with any of these modules".
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
hello Andrea,
my comments are in-line.
On Friday 20 March 2009 20:58:01 Andrea Aime wrote:
Raif S. Naffah ha scritto:
> hello all,
>
> apologies for the intrusion on the list but may i suggest an
> alternative to simply removing those extensions which could be a
> potential source of funding for the GeoServer developers: grade
> the extensions, say into three levels of quality (high, medium, and
> low) and continue publishing them. users can then judge for
> themselves and would know what to expect if they find a bug. this
> of course depends on a minimal level of functionalities these
> extensions should have --beyong getting compiled without errors
>
> later on, and on regular basis you could study the download figures
> and a decision to retire or change the grade of extensions can be
> made.
Mumble, what would the criteria be? Atm we have the following:
- whatever is in the core distribution is actually supported
and used by the developers
- real GeoServer extensions (i.e., imagemap, excel) have support,
they are just not considered of general interest enough to be part of
the core distribution but they could be considered high quality - a
number of data/coverage store (oracle I'm looking at you) extensions
may have a maintainer but the level of support on them is definitely
lower (medium)
- certain extensions are not really working, and we know it. We could
say they are "low" quality, but it's kind of a stretch since we
all know they have no maintainer at all -> support level on them is
zero solid. If you want to actually use them, better be a developer
that can fix any issue that might come up.
from what you describe i can see two categories: "supported" and
"unsupported" v/s today's list which does not qualify any of the
extensions. even a simple quality-related adjective could be enough
indication for the users to know what to expect.
I have troubles going out and tell the world "here, this is not
working and we know it". I mean, by the same token we could start
adding other stuff that's sitting in GT2 as well no? Looking into
geotools unsupported we have netcdf, geomedia, gpx, geometryless,
sql-datastore, tiger that are in no real better shape of the gml
datastore. Maybe they work, maybe they don't, no core dev really
knows any better than that (I never tried out the gml/vpf datastores
for example).
if these extensions can be built in the process of a standard release of
GeoServer then listing them with the "unsupported" qualifier could be a
source of information for users who may have plans to develop a similar
extension or contact the developer(s) behind the existing ones to
improve them.
Afaik the idea behind providing gml2 datastore was around the lines
of "let's see if anybody is interested enough to step up and become
maintainer of that stuff".
understood. as GeoServer gains more momentum and gets installed in more
sites as stand-alone or in combination with other applications, this
rationale remains valid. again just qualifying it as "unsupported"
could be enough for the expectations of those who may be interested in
it.
A more serious approach, imho, could be to list all of these and
point people to the sources: "Interested? Jump on the dev board and
help us with any of these modules".
cheers;
rsn