Hey Christian,
I certainly understand your desire to backport, I think we all have this
desire when we do something on master that improves a specific feature or
subsystem. But we have to have be disciplined on this regard so we try to
provide our selves with rules that determine if something is
"
I was thinking that once the "internal" store was completed it would be
basically included with the core module, and serve as the default so that
without more or less zero configuration you could fire up geoserver and
have a working csw. If others agree with that approach the name "default"
probabl
I struggle to understand the implications of the backport, but I wholely
support the development of the security fix. The demand for a solution
is there and semi-functional bits are just time-consuming and
frustrating for users. As a user, what I dont want is an upgrade to
geoserver that breaks
Greg Symo
Hi Everyone,
I am currently wrapping up the CSW work. The ISO MetaData has been fully
implemented and I'm now doing the final touches.
One question that arose was about the module structure.
So far we had chosen for the following structure. There are four modules:
* csw-api : interfaces and bas
+1
2012/12/5 Ben Caradoc-Davies
> On 04/12/12 18:56, Andrea Aime wrote:
> > Right, telling what public API is kind of hard in GeoServer.
> > Generally speaking I think in terms of extension points that people can
> > implement, plugins.
> > However I cannot imagine one that "plugs" the catalog r
Hi all
First, thanks for your votes.
Justin, I feared the discussion about the backport and I also feel
uncomfortable about the migration within 2.2.x. But lets have a look at
the current situation.
IMHO GSIP-82 is not a pure improvement proposal. In fact, it is a
cumulative bugfix (especially
On Wed, Dec 5, 2012 at 3:31 PM, Justin Deoliveira wrote:
> Hmmm, tricky problem.
>
> So I understand your proposal you are saying that we continue to store
> coverage names internally with a QName, but whenever we output a name we do
> it by replacing ":" with "_". And symmetrically whenever parsi
Hmmm, tricky problem.
So I understand your proposal you are saying that we continue to store
coverage names internally with a QName, but whenever we output a name we do
it by replacing ":" with "_". And symmetrically whenever parsing a name
handle the replacement as well?
A couple of ideas.
1. F
Tom van T
Andrea Ai
11 matches
Mail list logo
