I fully agree with you, but the point I am trying to make is that the number
of users a feature does have has to factor in to how we deprecate / remove
it.
Think back to validating wfs... it basically had zero users so when we made
the decision to pull it from core we did so without really any warning. And
nobody complained. But for KML, a feature that does have users, we at least
have to deprecate support before we remove. But it sounds like that is not
the conversation here despite Jody's over dramatic initial subject line.
On Sat, Jun 18, 2011 at 2:13 AM, Andrea Aime
<[email protected]>wrote:
> On Sat, Jun 18, 2011 at 3:55 AM, David Collins
> <[email protected]> wrote:
> > Geoserver will no longer produce KML as an output?
> >
> > This sounds like a fairly major discard - that means no more simple
> mashups
> > using Google Earth or Google Maps. Also, Geoserver has that really nice
> > dynamic interaction with Google Earth (using KMSCORE, etc.)
> >
> > To me, Google Earth is the one way to set up nice views of Geoserver
> data,
> > for regular/basic users, without writing code. (Well, just a little KML
> > code to define network links.)
> >
> > I'm not saying it shouldn't happen, but shouldn't there should be some
> > investigation about how many people are using the Geoserver to interact
> with
> > Google Earth?
> >
> > Or have I misunderstood?
>
> The core question is not how many people are using it, but how many people
> are willing to maintain it: if no one is willing to move a finger to
> maintain it having
> a million users of that feature won't help (unless some of them turn
> into contributors).
>
> Maintaining does not mean necessarily adding new features,
> but fixing bugs, making sure things are still working as other layers in
> the
> architecture get changed (like in this case), write docs for it and so on.
> It's the little things that keep a module in good shape, the big
> flashes of new features
> sure make people talk and drive business, but that's often not what keeps
> the
> software in one piece.
>
> That is not to say I'm never going to touch KML again (I did make the
> modifications
> needed in http://jira.codehaus.org/browse/GEOS-4597 to move the KML
> subsystem
> to the new API, and I would certainly work on it under contract) but
> I'm definitely
> not going to spend my spare time on it, that is already full
> maintaining referencing,
> shapefile, rendering, postgis, oracle, part of the coverage subsystem, svg,
> the
> various epsg databases, chart renderer in geotools, and good part of wms,
> wms cascading, sql views, wps, sfs, good part of the GUI in GeoServer (plus
> my
> duty as a PSC member to help in all core modules) and trying
> to care for overall performance in both systems.
>
> Long story short, if I have business reasons (customers) that need
> this or that KML function
> working I'll be happy to make it happen _during working hours_,
> otherwise... not.
>
> Cheers
> Andrea
>
>
> --
> -------------------------------------------------------
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax: +39 0584 962313
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> -------------------------------------------------------
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
