[Geoserver-devel] [Geotools-devel] New community module: XSLT based output format for WFS

GeoServer GeoServer Developer
1

Moving the thread the the geoserver mailing list (I did send the first mail to geotools-devel by mistake)

On Tue, Oct 2, 2012 at 3:13 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hey Andrea, +1 on the community module but some feedback inline as well for things to think about.

On Tue, Oct 2, 2012 at 4:34 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi all,
I want to propose a new community module, a customizable WFS output format which
will leverage XSLT to transform GML2/3 outputs into any text output.

Cool. One thing to consider is how the folks did this for app-schema. If you look for instance at GML3OutputFormat you will see support for an xslt transformation. In that case it is very specific but it would be good to think about how to do this in a general way that would be supported by the core wfs module.

Hmm… this would be a core change, but I need the module on 2.2.x as well.
How about a community module, and when the code is moved to extension in 2.2.x it is instead moved
into core on master?

The configuration will be XML based, one configuration file
file stored in $GEOSERVER_DATA_DIR/wfs-xslt/configuration.xml, with a format as follows:

Can we throw this under a directory named “wfs” to avoid proliferating new directories at the top level, eventually having it customizable per workspace as well (although i understand this can be put off as a future improvement).

Ah, indeed I have no mandate to make it work on a per workspace basis, but sure, I can put the configuration in a wfs directory.

It would also be good to have this customizable on a layer by layer basis. Which i would think is kind of important for general use right? Just thinking out loud but how often the case that you want a strctly general transform to be applied to all GML output, i would think tweaking the output of a single layer would make more sense. Although I guess this could also be done with a global file and just select the types you want.

Both use cases have a reason to exist, XLST can be used as a general format translator or as something very specific to
a certain layer.
What about adding bits to the configuration so that both can be achieved?

text/xml; subtype=gml/2.1.2
text/plain
txt
/path/to/the/xslt/file

…

When looking for a matching transformation the layer would be used as well.

There is a significant downside though, the general transformations can be advertised
among the wfs output formats in the caps document, the per layer one would make no
sense instead, and would probably have to be hidden instead, so they would end up
being a hidden contract between the server and the client (that’s why I did not want
to support them in the first place).

The format will not have a configuration GUI for the time being, but will be accompanied
by a REST configuration extension mimicking the configuration file structure:

/rest/wfs-xslt/formats/.xml

Again I think this shoudl fall under the existing /services/wfs endpoint. I would think something like:

/rest/services/wfs/transforms/…

ANd if supported on a layer by layer basis i think also available under the layer endpoint as well.

/rest/workspaces/…/featureTypes//transforms/…

Works for me (besides the doubts about the meaningfullness of a per layer output format in
the WFS framework).

Cool, agreed this will be a very powerful feature that is well received. I do think it is worth thinking about maybe a tighter integration with the core wfs/restconfig/etc… modules rather than as an add on.

About adding this to core, I also have the following hesitations:

  • XSLT can become memory bound, it all depends on what transformation sheet is used → it can be a bomb,
    not a very dangerous one since the admin controls the transformation sheet, but we also know that not all
    geoserver managers are equally skilled
  • core location is for code that is very popular, are we sure xslt transformations warrant this kind of status out of the box?
    Imho it would not set a good precedent for future decisions.

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

2

On Tue, Oct 2, 2012 at 7:29 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Moving the thread the the geoserver mailing list (I did send the first mail to geotools-devel by mistake)

On Tue, Oct 2, 2012 at 3:13 PM, Justin Deoliveira <jdeolive@anonymised.com501…> wrote:

Hey Andrea, +1 on the community module but some feedback inline as well for things to think about.

On Tue, Oct 2, 2012 at 4:34 AM, Andrea Aime <andrea.aime@anonymised.com…> wrote:

Hi all,
I want to propose a new community module, a customizable WFS output format which
will leverage XSLT to transform GML2/3 outputs into any text output.

Cool. One thing to consider is how the folks did this for app-schema. If you look for instance at GML3OutputFormat you will see support for an xslt transformation. In that case it is very specific but it would be good to think about how to do this in a general way that would be supported by the core wfs module.

Hmm… this would be a core change, but I need the module on 2.2.x as well.
How about a community module, and when the code is moved to extension in 2.2.x it is instead moved
into core on master?

Indeed, this is a problem for folks that need new functionality on stable branches. Doing it as a pure add on makes sense from a deployment point of view but I think can make the feature seem more awkward than it needs to be.

The proposed plan works fine for me but i would slightly modify it. Keep it as a community module now and when the time comes to push it up to a more supported state push it into the core on master, but leave it in community on 2.2.x. Rationale being that i think it would be weird to release the extension on the stable branch in one form and then change it (possibly significantly) on master.

What i usually do in this situation where a client needs functionality on the stable branch that is only available on the unstable is to maintain a custom branch for them. It adds a bit of overhead in the short term but I feel its better for the long term.

The configuration will be XML based, one configuration file
file stored in $GEOSERVER_DATA_DIR/wfs-xslt/configuration.xml, with a format as follows:

Can we throw this under a directory named “wfs” to avoid proliferating new directories at the top level, eventually having it customizable per workspace as well (although i understand this can be put off as a future improvement).

Ah, indeed I have no mandate to make it work on a per workspace basis, but sure, I can put the configuration in a wfs directory.

It would also be good to have this customizable on a layer by layer basis. Which i would think is kind of important for general use right? Just thinking out loud but how often the case that you want a strctly general transform to be applied to all GML output, i would think tweaking the output of a single layer would make more sense. Although I guess this could also be done with a global file and just select the types you want.

Both use cases have a reason to exist, XLST can be used as a general format translator or as something very specific to
a certain layer.
What about adding bits to the configuration so that both can be achieved?

text/xml; subtype=gml/2.1.2
text/plain
txt

/path/to/the/xslt/file

…

When looking for a matching transformation the layer would be used as well.

There is a significant downside though, the general transformations can be advertised
among the wfs output formats in the caps document, the per layer one would make no
sense instead, and would probably have to be hidden instead, so they would end up
being a hidden contract between the server and the client (that’s why I did not want
to support them in the first place).

Ahh ok, i see, missed the part about it being advertised as its own output format but that makes sense. Then yeah, it makes sense to keep it at the global/workspace level, and indeed i like the idea of being able to customize the transform for a specific layer in the configuration file.

The format will not have a configuration GUI for the time being, but will be accompanied
by a REST configuration extension mimicking the configuration file structure:

/rest/wfs-xslt/formats/.xml

Again I think this shoudl fall under the existing /services/wfs endpoint. I would think something like:

/rest/services/wfs/transforms/…

ANd if supported on a layer by layer basis i think also available under the layer endpoint as well.

/rest/workspaces/…/featureTypes//transforms/…

Works for me (besides the doubts about the meaningfullness of a per layer output format in
the WFS framework).

Right.

Cool, agreed this will be a very powerful feature that is well received. I do think it is worth thinking about maybe a tighter integration with the core wfs/restconfig/etc… modules rather than as an add on.

About adding this to core, I also have the following hesitations:

  • XSLT can become memory bound, it all depends on what transformation sheet is used → it can be a bomb,
    not a very dangerous one since the admin controls the transformation sheet, but we also know that not all
    geoserver managers are equally skilled

Right. WE could easily mitigate this though by adding a disable/enabled flag for transforms, making the default being disabled.

  • core location is for code that is very popular, are we sure xslt transformations warrant this kind of status out of the box?
    Imho it would not set a good precedent for future decisions.

Fair enough, but I also think it sets a bad precedent to tell people that new features can’t touch the core, even when it makes sense to do so.

How about the compromise of just adding it to the community release profile until there is a stronger mandate from the community to push it up to a more supported state. And who knows, at that time after the extension is fully implemented we might have a better idea of whether extension vs core is more appropriate.

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

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

3

On Tue, Oct 2, 2012 at 3:46 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Indeed, this is a problem for folks that need new functionality on stable branches. Doing it as a pure add on makes sense from a deployment point of view but I think can make the feature seem more awkward than it needs to be.

The proposed plan works fine for me but i would slightly modify it. Keep it as a community module now and when the time comes to push it up to a more supported state push it into the core on master, but leave it in community on 2.2.x. Rationale being that i think it would be weird to release the extension on the stable branch in one form and then change it (possibly significantly) on master.

Err… I really need this as part of the releases on the 2.2.x series, so the goal of making it
an extension is not something I can dodge. This is not against the release management
policies we voted, a module can always become an extension provided there is a PSC vote for it.
The request to force a different path seems peculiar to me, and as I said, I have no need for the module
to be in core (indeed this is your request).

That said, I see no trouble in have a module start as an extension in 2.2.x and become core in 2.3.x,
that’s indeed the natural evolution of an extension that manages to get popular enough.
As you say, the issue would arise if there is any significant change due to the integration in
core then we indeed have an issue, but I don’t see any comment in this direction.

There is a significant downside though, the general transformations can be advertised
among the wfs output formats in the caps document, the per layer one would make no
sense instead, and would probably have to be hidden instead, so they would end up
being a hidden contract between the server and the client (that’s why I did not want
to support them in the first place).

Ahh ok, i see, missed the part about it being advertised as its own output format but that makes sense. Then yeah, it makes sense to keep it at the global/workspace level, and indeed i like the idea of being able to customize the transform for a specific layer in the configuration file.

Ok, so how would this be played? Only transformations having global reach are exposed,
and if a layer has a custom one with the same output format name, it overrides the global one?
Later we can also add a workspace entry to make it configurable per workspace.

Wondering, what if a transformation is specific per layer? Not exposed, but working when invoked?

Cool, agreed this will be a very powerful feature that is well received. I do think it is worth thinking about maybe a tighter integration with the core wfs/restconfig/etc… modules rather than as an add on.

About adding this to core, I also have the following hesitations:

  • XSLT can become memory bound, it all depends on what transformation sheet is used → it can be a bomb,
    not a very dangerous one since the admin controls the transformation sheet, but we also know that not all
    geoserver managers are equally skilled

Right. WE could easily mitigate this though by adding a disable/enabled flag for transforms, making the default being disabled.

Without any configured transform the output format would be silent anyways

  • core location is for code that is very popular, are we sure xslt transformations warrant this kind of status out of the box?
    Imho it would not set a good precedent for future decisions.

Fair enough, but I also think it sets a bad precedent to tell people that new features can’t touch the core, even when it makes sense to do so.

The thing is, I don’t need it in core, it seems me it’s being fast tracked there for reasons that are not mentioned
in the discussion. Can’t we decide whether it’s core material later, based on its popularity?

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

4

On Tue, Oct 2, 2012 at 4:09 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Err… I really need this as part of the releases on the 2.2.x series, so the goal of making it

an extension is not something I can dodge. This is not against the release management
policies we voted, a module can always become an extension provided there is a PSC vote for it.
The request to force a different path seems peculiar to me, and as I said, I have no need for the module
to be in core (indeed this is your request).

Thinking about this, one clarification. What I’m proposing is an output format generator, pretty much
like the ogr2ogr one.

In the past XLST has also been discussed as a tool to restructure feature types exposed by a certain
layer, but this would be something totally different from what I’m proposing as it would need to:

  • alter also the DescribeFeatureType request
  • restructure the filters and property names incoming to fit the internal data model

The output format I’m proposing is there to allow a non programmer comfortable with XSTL to generate
stuff like reports, text outputs, HTML pages and other XML based outputs.
I don’t see it belonging into core more than the ogr2ogr output format in fact, it only has an easier way
to get into core since it has no external dependencies.

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

5

On Tue, Oct 2, 2012 at 8:09 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Tue, Oct 2, 2012 at 3:46 PM, Justin Deoliveira <jdeolive@anonymised.com…> wrote:

Indeed, this is a problem for folks that need new functionality on stable branches. Doing it as a pure add on makes sense from a deployment point of view but I think can make the feature seem more awkward than it needs to be.

The proposed plan works fine for me but i would slightly modify it. Keep it as a community module now and when the time comes to push it up to a more supported state push it into the core on master, but leave it in community on 2.2.x. Rationale being that i think it would be weird to release the extension on the stable branch in one form and then change it (possibly significantly) on master.

Err… I really need this as part of the releases on the 2.2.x series, so the goal of making it
an extension is not something I can dodge. This is not against the release management
policies we voted, a module can always become an extension provided there is a PSC vote for it.
The request to force a different path seems peculiar to me, and as I said, I have no need for the module
to be in core (indeed this is your request).

That said, I see no trouble in have a module start as an extension in 2.2.x and become core in 2.3.x,
that’s indeed the natural evolution of an extension that manages to get popular enough.
As you say, the issue would arise if there is any significant change due to the integration in
core then we indeed have an issue, but I don’t see any comment in this direction.

The trouble is that once we put the tag “extension” on it it is a released thing that we have to maintain backward compatibility for because it is endorsed. From where I sit it feels like being pushed to accept a feature and not really having a chance to provide any feedback for how it should best be implemented longer term. Which is why i thought keeping it a community module was a good compromise. Perhaps I am out of line but i feel like is something that developers have to account for when adding a new feature to the codebase, the fact that people might object, and that the customers expectations need to be set accordingly.

Anyways, I don’t think having it site outside the core wfs module is really going to be all that necessary, i just thought it would be nice since there is already code that is doing that there. So I am fine with keeping it an extension if that makes it easier all around.

There is a significant downside though, the general transformations can be advertised
among the wfs output formats in the caps document, the per layer one would make no
sense instead, and would probably have to be hidden instead, so they would end up
being a hidden contract between the server and the client (that’s why I did not want
to support them in the first place).

Ahh ok, i see, missed the part about it being advertised as its own output format but that makes sense. Then yeah, it makes sense to keep it at the global/workspace level, and indeed i like the idea of being able to customize the transform for a specific layer in the configuration file.

Ok, so how would this be played? Only transformations having global reach are exposed,
and if a layer has a custom one with the same output format name, it overrides the global one?
Later we can also add a workspace entry to make it configurable per workspace.

Yeah, this was my idea. I guess the idea is that an extension must override a global declaration.

Wondering, what if a transformation is specific per layer? Not exposed, but working when invoked?

Yeah, if we ensure there has to be a global transform, and then a specialization then it would be enough to simply declare all the global output formats in getcapabilities, and then at actual request time choose the one based on the layer. It might get messy if you have two layers being requested though. Which transform do you choose. Or do you apply them separately to each feature… not sure. Maybe sticking with one transform per output format like you originally proposed makes most sense.

Cool, agreed this will be a very powerful feature that is well received. I do think it is worth thinking about maybe a tighter integration with the core wfs/restconfig/etc… modules rather than as an add on.

About adding this to core, I also have the following hesitations:

  • XSLT can become memory bound, it all depends on what transformation sheet is used → it can be a bomb,
    not a very dangerous one since the admin controls the transformation sheet, but we also know that not all
    geoserver managers are equally skilled

Right. WE could easily mitigate this though by adding a disable/enabled flag for transforms, making the default being disabled.

Without any configured transform the output format would be silent anyways

  • core location is for code that is very popular, are we sure xslt transformations warrant this kind of status out of the box?
    Imho it would not set a good precedent for future decisions.

Fair enough, but I also think it sets a bad precedent to tell people that new features can’t touch the core, even when it makes sense to do so.

The thing is, I don’t need it in core, it seems me it’s being fast tracked there for reasons that are not mentioned
in the discussion. Can’t we decide whether it’s core material later, based on its popularity?

Its fine, it doesn’t need to be core, i just thought it made more sense there. And indeed user popularity is a criteria for moving something to extension as well. So it actually seems a bit odd that you are stating up front that it must be an extension.

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

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

6

On Tue, Oct 2, 2012 at 11:24 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

The trouble is that once we put the tag “extension” on it it is a released thing that we have to maintain backward compatibility for because it is endorsed. From where I sit it feels like being pushed to accept a feature and not really having a chance to provide any feedback for how it should best be implemented longer term. Which is why i thought keeping it a community module was a good compromise. Perhaps I am out of line but i feel like is something that developers have to account for when adding a new feature to the codebase, the fact that people might object, and that the customers expectations need to be set accordingly.

So far I’ve accepted all suggestions provided, even if I don’t really need them, which to me looks like “accounting for the community
feedback and not limiting oneself to the specific need of the customer”: changing the way stuff it’s configured (truly minor, not a problem)
and adding per layer support in both the engine and the rest API, which will require some extra effort,
and will also make sure it’s possible to add per workspace behavior later (should not be hard either).

If you have more feedback I’m open to discuss it, what’s putting me off at the moment is this “keep it in community
because I will want it in core later and will make changes to it that I can’t/don’t want to discuss now” stance.
I’m fully open to adapt the module to other needs and add extra behavior that makes sense, can’t we just
discuss your needs, factor them into the design as needed, and move on?

Btw, about long term support and extensions, extensions are not backed by the PSC and if the person providing
support for it drops down the module also goes, it already happened to WFS-V, also the WPS has been extension for
a whole stable release but we are changing the process names on 2.3.x (providing backwards compatibility of course),
so it’s not like we don’t have precedents of design decisions that have been changed in time.

Knowing your needs better we can either think about making them possible today or provide a smooth upgrade path
for them.

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

7

On Wed, Oct 3, 2012 at 1:18 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Tue, Oct 2, 2012 at 11:24 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

The trouble is that once we put the tag “extension” on it it is a released thing that we have to maintain backward compatibility for because it is endorsed. From where I sit it feels like being pushed to accept a feature and not really having a chance to provide any feedback for how it should best be implemented longer term. Which is why i thought keeping it a community module was a good compromise. Perhaps I am out of line but i feel like is something that developers have to account for when adding a new feature to the codebase, the fact that people might object, and that the customers expectations need to be set accordingly.

So far I’ve accepted all suggestions provided, even if I don’t really need them, which to me looks like “accounting for the community
feedback and not limiting oneself to the specific need of the customer”: changing the way stuff it’s configured (truly minor, not a problem)
and adding per layer support in both the engine and the rest API, which will require some extra effort,
and will also make sure it’s possible to add per workspace behavior later (should not be hard either).

If you have more feedback I’m open to discuss it, what’s putting me off at the moment is this “keep it in community
because I will want it in core later and will make changes to it that I can’t/don’t want to discuss now” stance.
I’m fully open to adapt the module to other needs and add extra behavior that makes sense, can’t we just
discuss your needs, factor them into the design as needed, and move on?

Btw, about long term support and extensions, extensions are not backed by the PSC and if the person providing
support for it drops down the module also goes, it already happened to WFS-V, also the WPS has been extension for
a whole stable release but we are changing the process names on 2.3.x (providing backwards compatibility of course),
so it’s not like we don’t have precedents of design decisions that have been changed in time.

Knowing your needs better we can either think about making them possible today or provide a smooth upgrade path
for them.

Ok, so what this tells me is that no matter how much the feature makes sense as part of the core as long as the person contributing it wants it to be an add-on, and wishes to push it to extension, we have to accept it?

Sorry, just trying to understand what sorts of feedback i am allowed to provide as a PSC member, because clearly i don’t understand what’s acceptable.

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

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

8

On Wed, Oct 3, 2012 at 1:42 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Knowing your needs better we can either think about making them possible today or provide a smooth upgrade path

for them.

Ok, so what this tells me is that no matter how much the feature makes sense as part of the core as long as the person contributing it wants it to be an add-on, and wishes to push it to extension, we have to accept it?

Sorry, just trying to understand what sorts of feedback i am allowed to provide as a PSC member, because clearly i don’t understand what’s acceptable.

I’d say, the usual feedback, technical, clear and to the point. “We should never get it to extension because maybe in the future I want to change things” is too vague,
does not give me a chance to address it, it’s basically an order or a veto, not a feedback

Please explain what you want that is not done as you’d expect in the current module so that we can discuss and find a solution
that hopefully suits everybody’s need. Until you don’t express what you want more in the module, or done differently, I have no way to respond.
What feature is missing, what design decision is wrong?

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

9

On Wed, Oct 3, 2012 at 6:19 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Wed, Oct 3, 2012 at 1:42 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Knowing your needs better we can either think about making them possible today or provide a smooth upgrade path

for them.

Ok, so what this tells me is that no matter how much the feature makes sense as part of the core as long as the person contributing it wants it to be an add-on, and wishes to push it to extension, we have to accept it?

Sorry, just trying to understand what sorts of feedback i am allowed to provide as a PSC member, because clearly i don’t understand what’s acceptable.

I’d say, the usual feedback, technical, clear and to the point. “We should never get it to extension because maybe in the future I want to change things” is too vague,
does not give me a chance to address it, it’s basically an order or a veto, not a feedback

Sorry, but this is not what i said. I suggested i thought i made more sense in core. You said that didn’t work not because you disagreed with it being in core, but because you needed it on 2.2.x. I suggested keeping it in community as a compromise. But I am so so sorry, that was way out of line.

Please explain what you want that is not done as you’d expect in the current module so that we can discuss and find a solution
that hopefully suits everybody’s need. Until you don’t express what you want more in the module, or done differently, I have no way to respond.
What feature is missing, what design decision is wrong?

Nothing, your right i am wrong. I apologize.

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

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

10

On Wed, Oct 3, 2012 at 2:52 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

I’d say, the usual feedback, technical, clear and to the point. “We should never get it to extension because maybe in the future I want to change things” is too vague,

does not give me a chance to address it, it’s basically an order or a veto, not a feedback

Sorry, but this is not what i said. I suggested i thought i made more sense in core. You said that didn’t work not because you disagreed with it being in core, but because you needed it on 2.2.x. I suggested keeping it in community as a compromise. But I am so so sorry, that was way out of line.

The whole discussion is based on the idea that you will want to modify it in core 2.3.x and don’t want to have backwards compatibility
with 2.2.x to maintain, but I’ve seen no hints about what you need to modify later.
If the module is ok as is we can have it as core on trunk and as an extension (if the PSC will vote positively) on 2.2.x.

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