Hi all,
I just put together a proposal for next round of virtual services, and the ability to configure services on a workspace by workspace basis.
http://geoserver.org/display/GEOS/GSIP+66±+Workspace+Local+Services
Feedback much appreciated.
-Justin
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Justin,
I am a bit concerned that more functionality is being layered on top of an incomplete model. Am I missing something or is there still an assumption of a one-to-one mapping between workspaces and namespaces? I support the idea of having per-workspace services, but until a workspace can contain multiple namespaces, this is of no use to anyone delivering related feature types in different namespaces.
app-schema users have on many occasions asked for the ability to deliver multiple profiles of their services from a GeoServer. For example, a service may be configured to deliver sa:LocatedSpecimen and its related om:Observations. Because a WFS service can only deliver a feature type once, it is not possible to deliver two different mappings of the data or two different encoding profiles. This would be possible if we had true workspaces workspaceOne and workspaceTwo that could each contain their own sa and om namespaces and each had their own WFS service endpoint. Without this functionality, users end up with multiple identical GeoServer instances differing only in their data directory.
In my view, the simplest way to regularise the delivery of services would be to not have a separate global service; this should just be the local service of the default workspace. Once you have a namespace and feature types appearing in multiple workspaces, you will not be able to determine which should be used for a "global service".
As an aside, as far as I understand it, the resource-publishing split has never been completed:
https://jira.codehaus.org/browse/GEOS-2881
http://geoserver.org/display/GEOS/GSIP+36+-+Resource+-+Publishing+Split+and+Virtual+Configuration
Kind regards,
Ben.
On 07/11/11 06:15, Justin Deoliveira wrote:
Hi all,
I just put together a proposal for next round of virtual services, and the ability to configure services on a workspace by workspace basis.
http://geoserver.org/display/GEOS/GSIP+66+-+Workspace+Local+Services
Feedback much appreciated.
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
Hey Ben,
Thanks for the input. Some comments line.
On Sun, Nov 6, 2011 at 8:13 PM, Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com wrote:
Justin,
I am a bit concerned that more functionality is being layered on top of an incomplete model. Am I missing something or is there still an assumption of a one-to-one mapping between workspaces and namespaces? I support the idea of having per-workspace services, but until a workspace can contain multiple namespaces, this is of no use to anyone delivering related feature types in different namespaces.
Understood, and indeed the long term vision is to break the coupling, and simply have namespace be an attribute of a layer, since its a publishing concern, not a data organizational one (at least not from an admin perspective). The short term reality is that there is a one to one relationship there to preserve backward compatibility. It actually should be pretty straight forward to remove this constraint, but up until now it seems no one has had a mandate to do so.
app-schema users have on many occasions asked for the ability to deliver multiple profiles of their services from a GeoServer. For example, a service may be configured to deliver sa:LocatedSpecimen and its related om:Observations. Because a WFS service can only deliver a feature type once, it is not possible to deliver two different mappings of the data or two different encoding profiles. This would be possible if we had true workspaces workspaceOne and workspaceTwo that could each contain their own sa and om namespaces and each had their own WFS service endpoint. Without this functionality, users end up with multiple identical GeoServer instances differing only in their data directory.
Right, again I think this becomes easy/easier to achieve once we break the workspace / namespace binding.
In my view, the simplest way to regularise the delivery of services would be to not have a separate global service; this should just be the local service of the default workspace. Once you have a namespace and feature types appearing in multiple workspaces, you will not be able to determine which should be used for a “global service”.
This is a fairly WFS centric view in which a “server” is divided up into “services” by wfs namespace, and one that is imo orthogonal to the virtual services approach, which is more about the admin side of things.
As an aside, as far as I understand it, the resource-publishing split has never been completed:
https://jira.codehaus.org/browse/GEOS-2881
http://geoserver.org/display/GEOS/GSIP+36±+Resource±+Publishing+Split+and+Virtual+Configuration
Unfortunately this has been more or less abandoned. While nice from a theoretical point of view practically I believe it is just too invasive an approach, and strays quite a bit from the way geoserver works today. It requires a serious mandate, lots of funding, and really it is a change that is on the same scale as the catalog/configuration rewrite… so realistically would cause us to spend probably a full release cycle flushing out regressions.
The workspace approach to virtual services was a much less ambitious approach, and while admittedly less elegant than a full resource - publishing split, it is capable of solving most of the same issues. So it was chosen mostly for pragmatic reasons.
Kind regards,
Ben.On 07/11/11 06:15, Justin Deoliveira wrote:
Hi all,
I just put together a proposal for next round of virtual services, and the ability to configure services on a workspace by workspace basis.
http://geoserver.org/display/GEOS/GSIP+66±+Workspace+Local+Services
Feedback much appreciated.
-Justin
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.–
Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
On Mon, Nov 7, 2011 at 4:13 AM, Ben Caradoc-Davies
<Ben.Caradoc-Davies@anonymised.com> wrote:
Justin,
I am a bit concerned that more functionality is being layered on top of
an incomplete model. Am I missing something or is there still an
assumption of a one-to-one mapping between workspaces and namespaces? I
support the idea of having per-workspace services, but until a workspace
can contain multiple namespaces, this is of no use to anyone delivering
related feature types in different namespaces.
Ben, it's the model we can get funding for, so it's the model we can afford.
The many entities that are funding GeoServer improvements today
are evidently not using complex features, and naturally they are pushing for
what they need.
Last time I wanted something really badly (WPS) I just ended up pushing it
in my spare time. For such large efforts it's really painful, but it
can be done.
Give it a thought.
Btw, app schema wise, you could really steal a page from the WPS effort.
It started humble but tried to provide out of the box something that people
could play with (a simple annotation driven api and a request builder).
Now that we have something people feel they can use funding is coming in
both as new processes (coming in monthly) and as new abilities (see the
asynch and general robustess work). We rarely see people interested
in complete green field development, they often want that 2% that is
missing from
the picture to satisfy their needs.
App-schema is there, I've been told it works, but honestly I would not consider
doing anything with it unless someone really asks for it, because it's just too
hard to setup. GeoServer users want a GUI, give one to them and you might
start seeing more people interested in using it, and also the funds it needs to
more forward.
Especially people that can access funding, they are often not the
techies that enjoy
eating XML for breakfast.
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
-------------------------------------------------------
On Sun, Nov 6, 2011 at 11:15 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
Hi all,
I just put together a proposal for next round of virtual services, and the
ability to configure services on a workspace by workspace basis.
http://geoserver.org/display/GEOS/GSIP+66+-+Workspace+Local+Services
Feedback much appreciated.
Looks good to me.
The only thing that perplexes me a bit is the GUI workflow, I guess it would
be better to have a flag that enables/disables custom workspace config instead,
and a way to "save and continue" in case the admin can access multiple
workspaces.
Also, what would be the workflow for a admin that can only access
specific workspaces,
and probably not the main configuration=
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
-------------------------------------------------------
On Tue, Nov 8, 2011 at 4:09 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
On Sun, Nov 6, 2011 at 11:15 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
Hi all,
I just put together a proposal for next round of virtual services, and the
ability to configure services on a workspace by workspace basis.
http://geoserver.org/display/GEOS/GSIP+66±+Workspace+Local+Services
Feedback much appreciated.Looks good to me.
The only thing that perplexes me a bit is the GUI workflow, I guess it would
be better to have a flag that enables/disables custom workspace config instead,
and a way to “save and continue” in case the admin can access multiple
workspaces.
Agreed, I couldn’t think of a great way to present this, but yeah… a checkbox would make more sense than what is there now.
Also, what would be the workflow for a admin that can only access
specific workspaces,
and probably not the main configuration=
I wonder… instead of trying to hijack the existing page should we perhaps add workspace specific service config to the workspace edit page? Basically underneath the namespace ui, default checkbox, etc… have a list of the services that have been customized for the workspace, with the ability to add/remove new ones, etc… Thoughts on that?
Cheers
Andrea–
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech leadVia Poggio alle Viti 1187
55054 Massarosa (LU)
Italyphone: +39 0584 962313
fax: +39 0584 962313http://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.
On Tue, Nov 8, 2011 at 3:26 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
The only thing that perplexes me a bit is the GUI workflow, I guess it
would
be better to have a flag that enables/disables custom workspace config
instead,
and a way to "save and continue" in case the admin can access multiple
workspaces.Agreed, I couldn't think of a great way to present this, but yeah... a
checkbox would make more sense than what is there now.
Maybe just disable everything unless the checkbox is enabled.
You should be able to get there by wrapping everything in a web markup
container and enable/disable it using the ajax event form control behavior.
Also, what would be the workflow for a admin that can only access
specific workspaces,
and probably not the main configuration=I wonder... instead of trying to hijack the existing page should we perhaps
add workspace specific service config to the workspace edit page? Basically
underneath the namespace ui, default checkbox, etc... have a list of the
services that have been customized for the workspace, with the ability to
add/remove new ones, etc... Thoughts on that?
It would make sense, it gets pretty obvious that the configs are there.
At the same time if an admin can only access only a specific workspace
the main links in the sidebar would be pretty confusing, a nicer workflow
for that case would be that the main link would directly bring you to that
service config for that specific workspace
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
-------------------------------------------------------
On Tue, Nov 8, 2011 at 7:44 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
On Tue, Nov 8, 2011 at 3:26 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
The only thing that perplexes me a bit is the GUI workflow, I guess it
would
be better to have a flag that enables/disables custom workspace config
instead,
and a way to “save and continue” in case the admin can access multiple
workspaces.Agreed, I couldn’t think of a great way to present this, but yeah… a
checkbox would make more sense than what is there now.Maybe just disable everything unless the checkbox is enabled.
You should be able to get there by wrapping everything in a web markup
container and enable/disable it using the ajax event form control behavior.
Yeah, that was the idea.
Also, what would be the workflow for a admin that can only access
specific workspaces,
and probably not the main configuration=I wonder… instead of trying to hijack the existing page should we perhaps
add workspace specific service config to the workspace edit page? Basically
underneath the namespace ui, default checkbox, etc… have a list of the
services that have been customized for the workspace, with the ability to
add/remove new ones, etc… Thoughts on that?It would make sense, it gets pretty obvious that the configs are there.
At the same time if an admin can only access only a specific workspace
the main links in the sidebar would be pretty confusing, a nicer workflow
for that case would be that the main link would directly bring you to that
service config for that specific workspace
Agreed. I was thinking we would wither (a) disable the links in the main sidebar or (b) switch them to the workspace specific ones. (b) would be ideal, (a) is naturally easier. There is also the issue of what to do when the user has access to multiple workspaces… which one takes precedence?
This issue overlaps with the finer grained admin security work that is going on at the moment in parallel. I think I may try to tackle this one as part of that proposal.
So… for this proposal how about just going with the links to the services on the workspace edit page? If we have that do we need to the checkbox on the service config page? Probably just want some indication that the config is workspace specific… but that can be done with a simple label.
And as part of the second proposal deal with having the main links in the side bar go to the config for the workspace(s) the admin actually has access to?
Cheers
Andrea–
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech leadVia Poggio alle Viti 1187
55054 Massarosa (LU)
Italyphone: +39 0584 962313
fax: +39 0584 962313http://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.
OK, I have updated the ui to reflect what was discussed here. I think the end result is much more intuitive. Updated screen shots and patch on the proposal.
On Tue, Nov 8, 2011 at 7:59 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
On Tue, Nov 8, 2011 at 7:44 AM, Andrea Aime <andrea.aime@anonymised.com.1268…> wrote:
On Tue, Nov 8, 2011 at 3:26 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
The only thing that perplexes me a bit is the GUI workflow, I guess it
would
be better to have a flag that enables/disables custom workspace config
instead,
and a way to “save and continue” in case the admin can access multiple
workspaces.Agreed, I couldn’t think of a great way to present this, but yeah… a
checkbox would make more sense than what is there now.Maybe just disable everything unless the checkbox is enabled.
You should be able to get there by wrapping everything in a web markup
container and enable/disable it using the ajax event form control behavior.Yeah, that was the idea.
Also, what would be the workflow for a admin that can only access
specific workspaces,
and probably not the main configuration=I wonder… instead of trying to hijack the existing page should we perhaps
add workspace specific service config to the workspace edit page? Basically
underneath the namespace ui, default checkbox, etc… have a list of the
services that have been customized for the workspace, with the ability to
add/remove new ones, etc… Thoughts on that?It would make sense, it gets pretty obvious that the configs are there.
At the same time if an admin can only access only a specific workspace
the main links in the sidebar would be pretty confusing, a nicer workflow
for that case would be that the main link would directly bring you to that
service config for that specific workspaceAgreed. I was thinking we would wither (a) disable the links in the main sidebar or (b) switch them to the workspace specific ones. (b) would be ideal, (a) is naturally easier. There is also the issue of what to do when the user has access to multiple workspaces… which one takes precedence?
This issue overlaps with the finer grained admin security work that is going on at the moment in parallel. I think I may try to tackle this one as part of that proposal.
So… for this proposal how about just going with the links to the services on the workspace edit page? If we have that do we need to the checkbox on the service config page? Probably just want some indication that the config is workspace specific… but that can be done with a simple label.
And as part of the second proposal deal with having the main links in the side bar go to the config for the workspace(s) the admin actually has access to?
Cheers
Andrea–
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech leadVia Poggio alle Viti 1187
55054 Massarosa (LU)
Italyphone: +39 0584 962313
fax: +39 0584 962313http://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.
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.