[Geoserver-devel] Death of KML scheduled for next week?

GeoServer GeoServer Developer
1

Hi Chris:

Andrea has been politely helping clean up some of the rendering code in GeoTools; but has not really asked in a blunt enough fashion on the geoserver-devel list.

The KML code is going to be need in of some serious QA and testing after this patch; do you have any developers who would be good for the work? We could arrange an IRC breakout session (and I could be available to answer any api change questions).

I don’t want to see this patch go ahead; and you learn about a sudden drop in quality when taking GeoServer into production at the end of this release cycle.

Basically:

  1. MapLayer was the general purpose swiss army knife of a class - it could handle anything and you would manage to cut your self on the little pair of scissors each time you used it
  2. It has been replaced by a carving set of tools each that does one thing explicitly
  3. Lots of KML code assume everything in a Map is a MapLayer and gets upset when a FeatureSource is not available

(Note this API change is from several releases of GeoTools ago; this is not a new change).

–
Jody Garnett

2

On Fri, Jun 17, 2011 at 3:39 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Hi Chris:

Andrea has been politely helping clean up some of the rendering code in GeoTools; but has not really asked in a blunt enough fashion on the geoserver-devel list.

The KML code is going to be need in of some serious QA and testing after this patch; do you have any developers who would be good for the work? We could arrange an IRC breakout session (and I could be available to answer any api change questions).

I don't want to see this patch go ahead; and you learn about a sudden drop in quality when taking GeoServer into production at the end of this release cycle.

"Death of kml" is of course exxagerated, but in fact I could only
check that the patch attached to
http://jira.codehaus.org/browse/GEOS-4597 builds, I did not attempt to
use any of the many
KML output forms, options and whatnot.
The code coverage is not high and I'm confident we'll see some
ClassCastException in some
code path in KML when the code tries to use a layer as a vector layer
(because it needs
a feature source and a style) when the old code chewed raster layers
the same way anyways
(I tried to pay attention, but it's a maze in there, not sure what all
the possible call paths are)

So it would really need someone to check and fix. I'm not volunteering
to be that person.

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

-------------------------------------------------------

3

Well since KML is maintainerless I think fairly all you can do is get things to compile and tests passing in KML (which should not be hard given the test coverage) and you are off the hook.

And since KML has become a liability we need to consider yanking it out and deprecating it. I am not sure if you are advocating that we remove it immediately Jody? I think we would at least have to give users one release cycle and announce clearly that we are dropping support for it.

2c.

On Fri, Jun 17, 2011 at 7:57 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Fri, Jun 17, 2011 at 3:39 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Hi Chris:

Andrea has been politely helping clean up some of the rendering code in GeoTools; but has not really asked in a blunt enough fashion on the geoserver-devel list.

The KML code is going to be need in of some serious QA and testing after this patch; do you have any developers who would be good for the work? We could arrange an IRC breakout session (and I could be available to answer any api change questions).

I don’t want to see this patch go ahead; and you learn about a sudden drop in quality when taking GeoServer into production at the end of this release cycle.

“Death of kml” is of course exxagerated, but in fact I could only
check that the patch attached to
http://jira.codehaus.org/browse/GEOS-4597 builds, I did not attempt to
use any of the many
KML output forms, options and whatnot.
The code coverage is not high and I’m confident we’ll see some
ClassCastException in some
code path in KML when the code tries to use a layer as a vector layer
(because it needs
a feature source and a style) when the old code chewed raster layers
the same way anyways
(I tried to pay attention, but it’s a maze in there, not sure what all
the possible call paths are)

So it would really need someone to check and fix. I’m not volunteering
to be that person.

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

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
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

4

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?

On Sat, Jun 18, 2011 at 7:47 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Well since KML is maintainerless I think fairly all you can do is get things to compile and tests passing in KML (which should not be hard given the test coverage) and you are off the hook.

And since KML has become a liability we need to consider yanking it out and deprecating it. I am not sure if you are advocating that we remove it immediately Jody? I think we would at least have to give users one release cycle and announce clearly that we are dropping support for it.

2c.

On Fri, Jun 17, 2011 at 7:57 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Fri, Jun 17, 2011 at 3:39 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Hi Chris:

Andrea has been politely helping clean up some of the rendering code in GeoTools; but has not really asked in a blunt enough fashion on the geoserver-devel list.

The KML code is going to be need in of some serious QA and testing after this patch; do you have any developers who would be good for the work? We could arrange an IRC breakout session (and I could be available to answer any api change questions).

I don’t want to see this patch go ahead; and you learn about a sudden drop in quality when taking GeoServer into production at the end of this release cycle.

“Death of kml” is of course exxagerated, but in fact I could only
check that the patch attached to
http://jira.codehaus.org/browse/GEOS-4597 builds, I did not attempt to
use any of the many
KML output forms, options and whatnot.
The code coverage is not high and I’m confident we’ll see some
ClassCastException in some
code path in KML when the code tries to use a layer as a vector layer
(because it needs
a feature source and a style) when the old code chewed raster layers
the same way anyways
(I tried to pay attention, but it’s a maze in there, not sure what all
the possible call paths are)

So it would really need someone to check and fix. I’m not volunteering
to be that person.

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

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
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.

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
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

5

I don’t think you have misunderstood - but just because a feature is popular does not imply that it has attracted funding and support.

I do not want to see KML pulled - I do want to highlight the fact it is suffering neglect.

Jody

On 18/06/2011, at 11:55 AM, David Collins <david.8.collins@anonymised.com> 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?

On Sat, Jun 18, 2011 at 7:47 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Well since KML is maintainerless I think fairly all you can do is get things to compile and tests passing in KML (which should not be hard given the test coverage) and you are off the hook.

And since KML has become a liability we need to consider yanking it out and deprecating it. I am not sure if you are advocating that we remove it immediately Jody? I think we would at least have to give users one release cycle and announce clearly that we are dropping support for it.

2c.

On Fri, Jun 17, 2011 at 7:57 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Fri, Jun 17, 2011 at 3:39 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Hi Chris:

Andrea has been politely helping clean up some of the rendering code in GeoTools; but has not really asked in a blunt enough fashion on the geoserver-devel list.

The KML code is going to be need in of some serious QA and testing after this patch; do you have any developers who would be good for the work? We could arrange an IRC breakout session (and I could be available to answer any api change questions).

I don’t want to see this patch go ahead; and you learn about a sudden drop in quality when taking GeoServer into production at the end of this release cycle.

“Death of kml” is of course exxagerated, but in fact I could only
check that the patch attached to
http://jira.codehaus.org/browse/GEOS-4597 builds, I did not attempt to
use any of the many
KML output forms, options and whatnot.
The code coverage is not high and I’m confident we’ll see some
ClassCastException in some
code path in KML when the code tries to use a layer as a vector layer
(because it needs
a feature source and a style) when the old code chewed raster layers
the same way anyways
(I tried to pay attention, but it’s a maze in there, not sure what all
the possible call paths are)

So it would really need someone to check and fix. I’m not volunteering
to be that person.

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

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
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
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
Geoserver-devel@anonymised.comt
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

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
Geoserver-devel@anonymised.com.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

6

Well since KML is maintainerless I think fairly all you can do is get things to compile and tests passing in KML (which should not be hard given the test coverage) and you are off the hook.

Aside: Only thing I could think of is doing some kind of regression test with the KML output (as a quick way to improve testing; if not junit test coverage). It would at least allow us to notice when the output changed.

And since KML has become a liability we need to consider yanking it out and deprecating it. I am not sure if you are advocating that we remove it immediately Jody?

Not advocating we remove it; just wanting to bring attention to “bit rot” in action. I would actually like it if we could find a source of funding for the kml support (as it is a much loved feature). I am led to understand that the internals are a bit scary and the code coverage is poor - is this the case?

I would hope that if KML continues to to not attracting funding we could knock it back to a community module / optional download etc.
Trouble is it would require a volunteer even to do that much.

I think we would at least have to give users one release cycle and announce clearly that we are dropping support for it.

Do we know of any developers who are using it? Perhaps we could introduce them in the role?

Aside: Sorry David Collins - we are looking for developers and not users here as we need someone to improve QA, accept new feature requests and so forth.

We could also canvas the developer and user lists first (or for those developers already present ask if your customers would like to add KML to their support contract?)

Cheers,
Jody

7

“Death of kml” is of course exxagerated, but in fact I could only check that the patch attached to http://jira.codehaus.org/browse/GEOS-4597 builds, I did not attempt to use any of the many KML output forms, options and whatnot.

Thanks for the insanely hard word on this Andrea, perhaps I should of said the “slow bit rot of KML”.

The code coverage is not high and I’m confident we’ll see some ClassCastException in some code path in KML when the code tries to use a layer as a vector layer (because it needs a feature source and a style) when the old code chewed raster layers the same way anyways
(I tried to pay attention, but it’s a maze in there, not sure what all the possible call paths are)

Andrea I have a patch that may attack the problem from the other end: https://jira.codehaus.org/browse/GEOT-3658

If I can ask for a review; the idea presented may not be great but I think it may be a good compromise.

So it would really need someone to check and fix. I’m not volunteering to be that person.

Agreed.

Jody

8

On Sat, Jun 18, 2011 at 3:55 AM, David Collins
<david.8.collins@anonymised.com> 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

-------------------------------------------------------

9

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 <andrea.aime@anonymised.com> wrote:

On Sat, Jun 18, 2011 at 3:55 AM, David Collins

<david.8.collins@anonymised.com> 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.

10

One thing I think I could volunteer for is in splitting kml as a
separate module. So that a first "downgrade" step would be moving it to
extension. Then if no maintainer steps up we could downgrade it to
community.
A first step towards "improving" the kml story was made while the wms
refactoring by placing kml into its own package instead of spread all
over the place. Still there's one point of conflict, and it's that the
WebMapService interface and DefaultWebMapService implementation are
directly tied to kml through the kml(GetMapRequest getMap):WebMap method
(i.e. the KML reflector), which somehow should end up in the kml
package/module itself.

So I for one, that happened to have to do one or another intervention in
the kml code base and still can't really say I _understand_ it, could at
least volunteer to try to make it its own module. Does that sound good?

Cheers,
Gabriel

On Sat, 2011-06-18 at 14:53 +1000, Jody Garnett wrote:

> Well since KML is maintainerless I think fairly all you can do is
> get things to compile and tests passing in KML (which should not be
> hard given the test coverage) and you are off the hook.
Aside: Only thing I could think of is doing some kind of regression
test with the KML output (as a quick way to improve testing; if not
junit test coverage). It would at least allow us to notice when the
output changed.
> And since KML has become a liability we need to consider yanking it
> out and deprecating it. I am not sure if you are advocating that we
> remove it immediately Jody?
Not advocating we remove it; just wanting to bring attention to "bit
rot" in action. I would actually like it if we could find a source of
funding for the kml support (as it is a much loved feature). I am led
to understand that the internals are a bit scary and the code coverage
is poor - is this the case?

I would hope that if KML continues to to not attracting funding we
could knock it back to a community module / optional download etc.
Trouble is it would require a volunteer even to do that much.
> I think we would at least have to give users one release cycle and
> announce clearly that we are dropping support for it.
Do we know of any developers who are using it? Perhaps we could
introduce them in the role?

Aside: Sorry David Collins - we are looking for developers and not
users here as we need someone to improve QA, accept new feature
requests and so forth.

We could also canvas the developer and user lists first (or for those
developers already present ask if your customers would like to add KML
to their support contract?)

Cheers,
Jody
------------------------------------------------------------------------------
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 Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers

11

On Sat, Jun 18, 2011 at 8:05 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

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.

I'm not going to argue there, KML is important, other servers are
picking it up too,
it would be bad to drop it.
That said, a lot of other things are important, and the number of
developers is what
it is.
In fact I'm not even arguing to move it away, just asking where the willing
maintainers for it are.
If Gabriel or anyone else is interested in keeping KML up then it can stay were
it is.

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.

Jody is trying to scare up someone saying "stop it, I am the one maintaining it"

The current situation leaves us, imho, four choices:
a) we dont' apply the patch and stall the MapContent/Layer adoption.
    I guess it's in the powers of the PSC to say that the risk/work is not worth
    its while (though of course that will have repercussions).
    Mind I'm not backing the MapContent/Layer patch in a strong way, I actually
    made it just to avoid stalling Jody/Michael, which are helping out
in geotools
    land mostly in their spare time (which makes, to me, the
contribution all the
    more important).
b) we apply the patch and say that it's ok if get KML somewhat broken bones
    out of it. Someone other than Andrea will care for it when the time comes
c) someone pops up and says he's interested in gettig KML to full capacity
   again after the patch is applied
d) we move kml out to extension like Gabriel proposes, recognizing kml code
   quality is going down without anyone stopping it.
   Mind one thing, while core status means PSC maintains it, extension status
   means there is an appointed person maintaining it. This may be Gabriel again,
   but I don't want to read too much in his mail

When I first posted the thread about the patch (not this one) I was
hoping someone
will pop up and go for c).
So far the only actual proposition we have is for d) (which is still
good, better than
no proposition at all).

Maybe things will change, if any business interest in KML pops back up
I'll be happy
to help. As I said, I'm just not available to do KML work Saturday and
Sunday, if it's
work time it's welcomed.

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

-------------------------------------------------------

12

On Sat, Jun 18, 2011 at 9:05 PM, Gabriel Roldán <groldan@anonymised.com> wrote:

One thing I think I could volunteer for is in splitting kml as a
separate module. So that a first "downgrade" step would be moving it to
extension. Then if no maintainer steps up we could downgrade it to
community.
A first step towards "improving" the kml story was made while the wms
refactoring by placing kml into its own package instead of spread all
over the place. Still there's one point of conflict, and it's that the
WebMapService interface and DefaultWebMapService implementation are
directly tied to kml through the kml(GetMapRequest getMap):WebMap method
(i.e. the KML reflector), which somehow should end up in the kml
package/module itself.

Interesting problem. The dispatcher now finds the service object first, and
then reflectively finds the method to call on it.
Since we cannot add methods to an object at runtime, do we have alternatives?
Maybe mapping the wms/kml... url to a specific restlet would be enough?

So I for one, that happened to have to do one or another intervention in
the kml code base and still can't really say I _understand_ it, could at
least volunteer to try to make it its own module. Does that sound good?

Would work for me. I'm still hoping to see someone pop up that says
she/he's interesting in helping maintenance, but if nobody shows up,
I guess we're not left with much of a choice

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

-------------------------------------------------------

13

Jody is trying to scare up someone saying “stop it, I am the one maintaining it”

Perhaps not quite that mean; what I am trying to say is we have a patch incoming that effects a lot of geoserver - and we have nobody
looking after KML. While you have done a great job to ensure it compiles and passes it’s tests I think asking for help or interested parties is a good idea.

b) we apply the patch and say that it’s ok if get KML somewhat broken bones
out of it. Someone other than Andrea will care for it when the time comes

This is my preference, it comes with the concern that we won’t hear about any trouble until the next full release of GeoServer (where a broader range of users try it out on their dataset).

Maybe things will change, if any business interest in KML pops back up I’ll be happy
to help. As I said, I’m just not available to do KML work Saturday and Sunday, if it’s
work time it’s welcomed.

With respect to (d) it is nice of gabriel to offer to help package it up; it strikes me as a good move for the code irrespective of this patch. I think as the PSC we can only keep the code compiling in the face of change and passing its tests; we should not overstep our abilities in “taking responsibility”.

Jody