[Geoserver-devel] Layer names, resource aliases

[Andrea_Aime3]

Hi,
looking into the Wicket UI configuration panels
a question came up.

As you may know, in 1.7.x we already have an
"alias" field that allow for renaming feature
types before publication.
That feature works only for vector layers.

On trunk we're using the new catalog objects
directly and the situation is... somewhat
funny.
ResourceInfo has an alias field. Meaning,
it can be configured for both vectors and
rasters, thought only vectors have the machinery
for resource renaming in place (only the
type, not the attributes).

In LayerInfo we have a property name, that atm
is editable, and that is not necessarily the
resource name, not its alias (oh my).
As the icing on the cake, afaik WFS and WCS
use resources directly, not layers, so the
layer name is pretty much ignored, _but_,
always afaik, WMS has been recoded to use layers,
so WMS will see the layer name but not the
resource alias.

I guess we need to make up our minds and decide
on _one_ way to rename stuff.
I guess the best long term solution is to use
the layer name?
But then again, that is not namespaced. Do
we namespace it? Does it make sense?
Also, doing that would require to re-hook
WFS and WCS to layers as opposed to resources.
Not doing that would leave WMS as the "oddball"
that uses the layer names instead (hmmm... how
are namespaces handled there now???)
Glab...

Opinions?

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

[Justin_Deoliveira]

Hi Andrea,

Yes, I agree that the situation now is not ideal. Currently ResourceInfo has:

getName() -> its published name (what we call alias today)
getNativeName() -> the physical name
getAlias() -> collection of "aliases"

I believe we achieve aliasing now with getName() and getNativeName().

I agree that Layer.getName() is the best long term solution for a published name. But as you point out this requires that we have services go through Layers, not resources -> ie, the resource/publishing split we oh so long for. Part of that is introducing maps so that layer names can be qualified. So the map will become the "namespace" for the layer name.

Or at least that is how i see it playing out.

Andrea Aime wrote:

Hi,
looking into the Wicket UI configuration panels
a question came up.

As you may know, in 1.7.x we already have an
"alias" field that allow for renaming feature
types before publication.
That feature works only for vector layers.

On trunk we're using the new catalog objects
directly and the situation is... somewhat
funny.
ResourceInfo has an alias field. Meaning,
it can be configured for both vectors and
rasters, thought only vectors have the machinery
for resource renaming in place (only the
type, not the attributes).

In LayerInfo we have a property name, that atm
is editable, and that is not necessarily the
resource name, not its alias (oh my).
As the icing on the cake, afaik WFS and WCS
use resources directly, not layers, so the
layer name is pretty much ignored, _but_,
always afaik, WMS has been recoded to use layers,
so WMS will see the layer name but not the
resource alias.

I guess we need to make up our minds and decide
on _one_ way to rename stuff.
I guess the best long term solution is to use
the layer name?
But then again, that is not namespaced. Do
we namespace it? Does it make sense?
Also, doing that would require to re-hook
WFS and WCS to layers as opposed to resources.
Not doing that would leave WMS as the "oddball"
that uses the layer names instead (hmmm... how
are namespaces handled there now???)
Glab...

Opinions?

Cheers
Andrea

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

[Andrea_Aime3]

Justin Deoliveira ha scritto:

Hi Andrea,

Yes, I agree that the situation now is not ideal. Currently ResourceInfo has:

getName() -> its published name (what we call alias today)
getNativeName() -> the physical name
getAlias() -> collection of "aliases"

Mind, alias has never been a collection. It was implemented
as a way to rename a feature type, not to provide a second
name for it. But the name it was give created (and is still
creating) confusion.

I believe we achieve aliasing now with getName() and getNativeName().

Oh, do we? This is new to me. But then again, I don't have good
grips on how the catalog works right now. So the resource pool
applies a retyping data store using getName()?

I agree that Layer.getName() is the best long term solution for a published name. But as you point out this requires that we have services go through Layers, not resources -> ie, the resource/publishing split we oh so long for. Part of that is introducing maps so that layer names can be qualified. So the map will become the "namespace" for the layer name.

It would be the namespace prefix that we use today. But not a real
WFS namespace. So, will we associate a real namespace URI to maps
as well? Or we take the native one coming from the resource?
(assuming there is no community schema mapping)

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

[Justin_Deoliveira]

Andrea Aime wrote:

Justin Deoliveira ha scritto:

Hi Andrea,

Yes, I agree that the situation now is not ideal. Currently ResourceInfo has:

getName() -> its published name (what we call alias today)
getNativeName() -> the physical name
getAlias() -> collection of "aliases"

Mind, alias has never been a collection. It was implemented
as a way to rename a feature type, not to provide a second
name for it. But the name it was give created (and is still
creating) confusion.

Yeah... I think alias is not the best name for the function it provides, and this is something i tried to fix when i revamped the model. If we do not have any useful function for an actual "alias", that is a secondary name for a layer, then i suggest we remove it to prevent further confusion.

I believe we achieve aliasing now with getName() and getNativeName().

Oh, do we? This is new to me. But then again, I don't have good
grips on how the catalog works right now. So the resource pool
applies a retyping data store using getName()?

Yup, RP checks if getName() != getNativeName() and if true applies the retyping data store.

I agree that Layer.getName() is the best long term solution for a published name. But as you point out this requires that we have services go through Layers, not resources -> ie, the resource/publishing split we oh so long for. Part of that is introducing maps so that layer names can be qualified. So the map will become the "namespace" for the layer name.

It would be the namespace prefix that we use today. But not a real
WFS namespace. So, will we associate a real namespace URI to maps
as well? Or we take the native one coming from the resource?
(assuming there is no community schema mapping)

I am not sure i follow. The original question is how do we make layer names unique? My answer was that once layers are grouped by map, the name of the map becomes the qualifier. Exactly how we look up stores today, qualifying them with a workspace. Am i making any sense?

In terms of "namespaces", I think a namespace should just refer to an attribute of a Layer. Not a grouping mechanism. Workspaces and maps are the grouping mechanisms. Sure a bunch of layers can have the same namespace... but i don't think they should be "grouped" by that namespace per se.

Cheers
Andrea

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

[Rob_Atkinson1]

Oh dear

doesnt an oversimplification always cause headaches..

A couple of observations that have not yet been made...

1) A Layer is not the same as a FeatureType, semantically. Hence
assuming they are the same will always cause a problem. For example, a
RoadNetowrk may consist of roads, bridges, junctions, stop signs etc,
all of which are also useful FeatureTypes, but the WMS always wants to
show the network...

2) Layers do have a "namespace" - they are scoped unique to the WMS service.

3) To make layers globally meaningful you need an out-of-band
agreement - like a naming convention, or ability to tag a Layer via
its Keywords with an identifier.

4) Renaming is fully supported by the application-schema
implementation, which does it properly, and can rename attributes.
What I suspect you really want is a GML Simple Features Level 0
profile conveience API into app-schemas, with the ability to create an
"anonymous schema" by introspection the way you do at the moment.

I can only lead you to water, not make you drink, but I think these
perspectives might at least allow you to untangle what should be going
on, even if you do decide to maintain a point solution to "renaming".

Rob

On Fri, Mar 20, 2009 at 6:15 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Andrea Aime wrote:

Justin Deoliveira ha scritto:

Hi Andrea,

Yes, I agree that the situation now is not ideal. Currently
ResourceInfo has:

getName() -> its published name (what we call alias today)
getNativeName() -> the physical name
getAlias() -> collection of "aliases"

Mind, alias has never been a collection. It was implemented
as a way to rename a feature type, not to provide a second
name for it. But the name it was give created (and is still
creating) confusion.

Yeah... I think alias is not the best name for the function it provides,
and this is something i tried to fix when i revamped the model. If we do
not have any useful function for an actual "alias", that is a secondary
name for a layer, then i suggest we remove it to prevent further confusion.

I believe we achieve aliasing now with getName() and getNativeName().

Oh, do we? This is new to me. But then again, I don't have good
grips on how the catalog works right now. So the resource pool
applies a retyping data store using getName()?

Yup, RP checks if getName() != getNativeName() and if true applies the
retyping data store.

I agree that Layer.getName() is the best long term solution for a
published name. But as you point out this requires that we have
services go through Layers, not resources -> ie, the
resource/publishing split we oh so long for. Part of that is
introducing maps so that layer names can be qualified. So the map will
become the "namespace" for the layer name.

It would be the namespace prefix that we use today. But not a real
WFS namespace. So, will we associate a real namespace URI to maps
as well? Or we take the native one coming from the resource?
(assuming there is no community schema mapping)

I am not sure i follow. The original question is how do we make layer
names unique? My answer was that once layers are grouped by map, the
name of the map becomes the qualifier. Exactly how we look up stores
today, qualifying them with a workspace. Am i making any sense?

In terms of "namespaces", I think a namespace should just refer to an
attribute of a Layer. Not a grouping mechanism. Workspaces and maps are
the grouping mechanisms. Sure a bunch of layers can have the same
namespace... but i don't think they should be "grouped" by that
namespace per se.

Cheers
Andrea

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

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Andrea_Aime3]

Rob Atkinson ha scritto:

Oh dear

doesnt an oversimplification always cause headaches..

Pretty much like un-necessary complexity...

A couple of observations that have not yet been made...

1) A Layer is not the same as a FeatureType, semantically. Hence
assuming they are the same will always cause a problem. For example, a
RoadNetowrk may consist of roads, bridges, junctions, stop signs etc,
all of which are also useful FeatureTypes, but the WMS always wants to
show the network...

The fact that we now have a Layer and a FeatureType should be hint
enough that we recognize they are separate things. But we cannot
just split them up fully without pouring in a significant amount of work, so for the moment they will still walk together as in old
times.

4) Renaming is fully supported by the application-schema
implementation, which does it properly, and can rename attributes.
What I suspect you really want is a GML Simple Features Level 0
profile conveience API into app-schemas, with the ability to create an
"anonymous schema" by introspection the way you do at the moment.

Last time I checked application-schema datastore was read only?
And GeoServer must do WFS-T. What I really want is something that
allows me to rename attributes and map types on simple features
without:
1) getting a significant drop in performance
2) loosing the ability to write
If the application schema datastore can evolve to this point,
excellent, otherwise I'll roll out something simpler that handles
efficiently and effectively the common and simple case.

I can only lead you to water, not make you drink,

Very condescending and unasked for. I won't comment any further.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

[Rob_Atkinson1]

Last time I checked application-schema datastore was read only?

Yes it is, but we should discuss this as part of the next steps strategy work.

And GeoServer must do WFS-T. What I really want is something that
allows me to rename attributes and map types on simple features
without:
1) getting a significant drop in performance
2) loosing the ability to write

This is perfectly reasonable set of objective criteria - its always
reasonable to put in optimisations for common special cases, but best
to do this against a design capable of handling all cases that will
matter.

If the application schema datastore can evolve to this point,
excellent, otherwise I'll roll out something simpler that handles
efficiently and effectively the common and simple case.

Its obviously expected that you will need to do this - the questions are:
1) can this be removed easily enough if a general solution emerges?
2) does rolling this out involve adding unsafe or unnecessarily
restrictive assumptions into parts of the code base?

I'm sure it can be done in a way which keeps these issues in mind.

I can only lead you to water, not make you drink,

Very condescending and unasked for. I won't comment any further.

You are right, just because these issues werent discussed doesnt mean
blindness to them, that was unwarranted - I apologise. This isnt the
first time the Layer <> FT issue has arisen, and I guess it wont be
the last, I should be more patient.

Rob

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

[Andrea_Aime3]

Rob Atkinson ha scritto:

Last time I checked application-schema datastore was read only?

Yes it is, but we should discuss this as part of the next steps strategy work.

This is sure interesting. Do you have a longer term plan
about this?

And GeoServer must do WFS-T. What I really want is something that
allows me to rename attributes and map types on simple features
without:
1) getting a significant drop in performance
2) loosing the ability to write

This is perfectly reasonable set of objective criteria - its always
reasonable to put in optimisations for common special cases, but best
to do this against a design capable of handling all cases that will
matter.

In an ideal world, yes, but practice does not always agree with that.
The "general" case architecture usually has to do a lot more
work in order to deal with its generality, sometimes you can
just add a few checks in core places and you get the best
bang for the buck... and sometimes its clear that performance
was not considered during design and it's simply impossible,
or too hard, to retrofit it later.

If the application schema datastore can evolve to this point,
excellent, otherwise I'll roll out something simpler that handles
efficiently and effectively the common and simple case.

Its obviously expected that you will need to do this - the questions are:
1) can this be removed easily enough if a general solution emerges?

The current RW type renamer is just a wrapper around datastores
and feature collections. It could conceivably be evolved into
something that does simple renaming and type mapping keeping
a decent performance profile and without loosing RW capabilities.
As for easy of removal, it's currently hooked up into
the FeatureSource building chain by something like 15 lines of code
in a single method of ResourcePool.
Cannot get any easier to remove than this.

2) does rolling this out involve adding unsafe or unnecessarily
restrictive assumptions into parts of the code base?

Hmmm... I would not think so. If we ended up doing this the
harder to switch out part would be the mapping configuration.
But for sure I would make it so that it follows the current design
principle: _nothing_ outside of the classes that build up
the FeatureSource for the rest of GeoServer would know about it.
The rest would just play ball as usual, not knowing that the
FS it's playing against is actually a dynamic feature mapper.

And I want this kind of design for application schema as well.
Granted code modifications are needed to support complex
features, but I really do hope we won't have to make changes
in services to support application-schema mapping (besides
the WFS references to external, non GS generated schemas).

Cheers
Andrea

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

[Andrea_Aime3]

Justin Deoliveira ha scritto:
...

Mind, alias has never been a collection. It was implemented
as a way to rename a feature type, not to provide a second
name for it. But the name it was give created (and is still
creating) confusion.

Yeah... I think alias is not the best name for the function it provides, and this is something i tried to fix when i revamped the model. If we do not have any useful function for an actual "alias", that is a secondary name for a layer, then i suggest we remove it to prevent further confusion.

Agreed. http://jira.codehaus.org/browse/GEOS-2774

I agree that Layer.getName() is the best long term solution for a published name. But as you point out this requires that we have services go through Layers, not resources -> ie, the resource/publishing split we oh so long for. Part of that is introducing maps so that layer names can be qualified. So the map will become the "namespace" for the layer name.

It would be the namespace prefix that we use today. But not a real
WFS namespace. So, will we associate a real namespace URI to maps
as well? Or we take the native one coming from the resource?
(assuming there is no community schema mapping)

I am not sure i follow. The original question is how do we make layer names unique? My answer was that once layers are grouped by map, the name of the map becomes the qualifier. Exactly how we look up stores today, qualifying them with a workspace. Am i making any sense?

In terms of "namespaces", I think a namespace should just refer to an attribute of a Layer. Not a grouping mechanism. Workspaces and maps are the grouping mechanisms. Sure a bunch of layers can have the same namespace... but i don't think they should be "grouped" by that namespace per se.

Works for me.

So for the moment we have to avoid confusing the users more than necessary. It seems to me the following solution could apply as
long as we don't have a real resource/publishing split:
- have the ResourceInfo name be editable (it's not atm)
- have the LayerInfo name be non editable, and always
   equal to the resource info one. We'll make it editable
   again when a real resource/layer split will be worked on.

The latter will keep the current wms/wfs/wcs relantionship where
the same resource has the same name regardless of what service
you use to access it (as opposed to start confusing
the users as to why topp:states is available on wfs, but
on wms you have to call it MyEditedLayerName only because
the user changed the layer name by accident).

I'm wondering how to tackle the second part thought. UI
wise I can make that happen and it's easy, but what about
REST config, or anyone fiddling directly in the xml files
(I know, not supported, but people will do it anyways)?
Wondering if implementation wise we should,
just for the moment, wire the layer name directly onto
its resource one (have LayerInfoImpl.getName() forward
to getResource().getName()).

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

[Justin_Deoliveira]

Andrea Aime wrote:

Justin Deoliveira ha scritto:
...

Mind, alias has never been a collection. It was implemented
as a way to rename a feature type, not to provide a second
name for it. But the name it was give created (and is still
creating) confusion.

Yeah... I think alias is not the best name for the function it provides, and this is something i tried to fix when i revamped the model. If we do not have any useful function for an actual "alias", that is a secondary name for a layer, then i suggest we remove it to prevent further confusion.

Agreed. http://jira.codehaus.org/browse/GEOS-2774

I agree that Layer.getName() is the best long term solution for a published name. But as you point out this requires that we have services go through Layers, not resources -> ie, the resource/publishing split we oh so long for. Part of that is introducing maps so that layer names can be qualified. So the map will become the "namespace" for the layer name.

It would be the namespace prefix that we use today. But not a real
WFS namespace. So, will we associate a real namespace URI to maps
as well? Or we take the native one coming from the resource?
(assuming there is no community schema mapping)

I am not sure i follow. The original question is how do we make layer names unique? My answer was that once layers are grouped by map, the name of the map becomes the qualifier. Exactly how we look up stores today, qualifying them with a workspace. Am i making any sense?

In terms of "namespaces", I think a namespace should just refer to an attribute of a Layer. Not a grouping mechanism. Workspaces and maps are the grouping mechanisms. Sure a bunch of layers can have the same namespace... but i don't think they should be "grouped" by that namespace per se.

Works for me.

So for the moment we have to avoid confusing the users more than necessary. It seems to me the following solution could apply as
long as we don't have a real resource/publishing split:
- have the ResourceInfo name be editable (it's not atm)
- have the LayerInfo name be non editable, and always
  equal to the resource info one. We'll make it editable
  again when a real resource/layer split will be worked on.

Yeah, I think this will work with one caveat. We need to get the ID's set up properly. Currently id is always == name... we should change that. Once that is in place we can make the REsourceInfo name editable.

The latter will keep the current wms/wfs/wcs relantionship where
the same resource has the same name regardless of what service
you use to access it (as opposed to start confusing
the users as to why topp:states is available on wfs, but
on wms you have to call it MyEditedLayerName only because
the user changed the layer name by accident).

I'm wondering how to tackle the second part thought. UI
wise I can make that happen and it's easy, but what about
REST config, or anyone fiddling directly in the xml files
(I know, not supported, but people will do it anyways)?
Wondering if implementation wise we should,
just for the moment, wire the layer name directly onto
its resource one (have LayerInfoImpl.getName() forward
to getResource().getName()).

Yeah... that is probably a good idea until we have the true split. +1.

Cheers
Andrea

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

[Andrea_Aime3]

Justin Deoliveira ha scritto:

Yeah, I think this will work with one caveat. We need to get the ID's set up properly. Currently id is always == name... we should change that. Once that is in place we can make the REsourceInfo name editable.

And what is involved in doing that?
Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

[Justin_Deoliveira]

Andrea Aime wrote:

Justin Deoliveira ha scritto:

Yeah, I think this will work with one caveat. We need to get the ID's set up properly. Currently id is always == name... we should change that. Once that is in place we can make the REsourceInfo name editable.

And what is involved in doing that?

Should not be too much work. Basically just change CatalogImpl.sync() to instead of set the id from the name, to generate a universally unique one.

Second will be to isolate any calls to Catalog that look up an object by id, and change to them to look up by name (if its appropriate). As far as i know the only code that should look up by id is the UI.

Cheers
Andrea

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

[robert.woodcock]

Andrea Aime asked:

Last time I checked application-schema datastore was read only?

Yes it is, but we should discuss this as part of the next steps strategy work.

This is sure interesting. Do you have a longer term plan about this?

I'll catch this one since I'm responsible for much of the strategy and associated funding that Ben and Rini are using to implement app-schema.

With respect to WFS-T support, it is on the list of "could-have" requirements. In Australia there is legislation that requires Industry to report some spatial information (mostly minerals exploration related) back to Government agencies. It has been suggested a number of times that this could be facilitated using WFS-T with GML application schemas like GeosciML. The trouble is, even if the feature was implemented, there are still cultural barriers that prevent this from happening. We won't be moving to add app-schema WFS-T support until we start to see the culture for the current publishing phase establishing. There are also a couple of other features higher up on the list of requests.

The immediate future (between now and June this year) is to complete app-schema read-only and have it deployed at a number of Australian geological surveys and research organisations (like my own) against production databases publishing GeosciML and similar GML application schemas. We're expecting this deployment will lead to a number of requests for improvement around configuration, performance and bugs we didn't catch in the tests.

We're currently funded until June 2011 (2 more years) and will continue to support this activity during that time. All improvements, fixes etc will be returned to the Geoserver community as per current activities (and we've been delighted at the response of the geoserver community to our contributions). We will also continue to watch the geoserver mailing lists and where we can (which I expect will be quite a lot) we'll look at issues coming in from the broader community as well.

Whilst we aren't currently active on the WFS-T app-schema support, if someone wanted to work on this then we would be happy to collaborate on it to aid the process. Its also entirely possible if things go well with our other priorities, we will get to it in the next couple of years just because it would nice to have the full read-write feature completed and we will eventually need it.

Regards,

Rob

Dr Robert Woodcock
Auscope Grid - Director, Senior Research Scientist
CSIRO Exploration and Mining
ARRC (Australian Resources Research Centre)
26 Dick Perry Avenue, Kensington WA 6151, Australia
PO Box 1130, Bentley WA 6102, Australia
Ph: 08 6436.8780 | E: Robert.Woodcock@anonymised.com | W: www.csiro.au

-----Original Message-----
From: Andrea Aime [mailto:aaime@anonymised.com]
Sent: Friday, 20 March 2009 4:36 PM
To: Rob Atkinson
Cc: Geoserver-devel; Justin Deoliveira
Subject: Re: [Geoserver-devel] Layer names, resource aliases

Rob Atkinson ha scritto:

Last time I checked application-schema datastore was read only?

Yes it is, but we should discuss this as part of the next steps strategy work.

This is sure interesting. Do you have a longer term plan
about this?

And GeoServer must do WFS-T. What I really want is something that
allows me to rename attributes and map types on simple features
without:
1) getting a significant drop in performance
2) loosing the ability to write

This is perfectly reasonable set of objective criteria - its always
reasonable to put in optimisations for common special cases, but best
to do this against a design capable of handling all cases that will
matter.

In an ideal world, yes, but practice does not always agree with that.
The "general" case architecture usually has to do a lot more
work in order to deal with its generality, sometimes you can
just add a few checks in core places and you get the best
bang for the buck... and sometimes its clear that performance
was not considered during design and it's simply impossible,
or too hard, to retrofit it later.

If the application schema datastore can evolve to this point,
excellent, otherwise I'll roll out something simpler that handles
efficiently and effectively the common and simple case.

Its obviously expected that you will need to do this - the questions are:
1) can this be removed easily enough if a general solution emerges?

The current RW type renamer is just a wrapper around datastores
and feature collections. It could conceivably be evolved into
something that does simple renaming and type mapping keeping
a decent performance profile and without loosing RW capabilities.
As for easy of removal, it's currently hooked up into
the FeatureSource building chain by something like 15 lines of code
in a single method of ResourcePool.
Cannot get any easier to remove than this.

2) does rolling this out involve adding unsafe or unnecessarily
restrictive assumptions into parts of the code base?

Hmmm... I would not think so. If we ended up doing this the
harder to switch out part would be the mapping configuration.
But for sure I would make it so that it follows the current design
principle: _nothing_ outside of the classes that build up
the FeatureSource for the rest of GeoServer would know about it.
The rest would just play ball as usual, not knowing that the
FS it's playing against is actually a dynamic feature mapper.

And I want this kind of design for application schema as well.
Granted code modifications are needed to support complex
features, but I really do hope we won't have to make changes
in services to support application-schema mapping (besides
the WFS references to external, non GS generated schemas).

Cheers
Andrea

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel