[Geoserver-devel] workspaces

GeoServer GeoServer Developer
1

So in 2.0 we've got this new concept of 'workspaces' that are a bit transitional.

Before 2.0 the only way to group featureTypes was with namespaces.

In 2.1 we should have a full resource publishing split, with a strong concept of workspaces as collections of layers. Each workspace should have its own capabilities document, its own set of permissions, etc.

In 2.0 we basically just decided that 'namespaces' (particularly namespace prefixes) are equivalent to 'workspaces'. I think this is trying to squeeze too many concepts in to one. We generally want namespace prefixes to be pretty short, ideally 3-4 characters. But we have no good way of hinting to people that they should probably use shorter names for their workspaces.

What I'd like to propose is that a 'workspace' consist of three things:
* A title
* A short name
* A URI

The title is used in the UI, and also in capabilities reporting on service information.

The short name is used for the namespace prefix, and in the url, like in the rest API.

The URI is for the namespace, what the prefix points to. If people don't fill it out we'll default it to like http://geoserver.org/shortname or something.

The short name will have a character limit (I'd say 5 or 6), and if the title is not filled out then short name will just be used.

What do people think? I'm not saying we need to get it in 2.0.x, but it's worth thinking about.

I bring it up because I think we're trying to squeeze too much in to the 'workspace'.

--
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.

2

Hey Chris,

Chris Holmes wrote:

So in 2.0 we've got this new concept of 'workspaces' that are a bit transitional.

Before 2.0 the only way to group featureTypes was with namespaces.

In 2.1 we should have a full resource publishing split, with a strong concept of workspaces as collections of layers. Each workspace should have its own capabilities document, its own set of permissions, etc.

Not quite, I think you may be confusing the concept of workspace and map, as the current design has it. In the current design, post 2.1 workspaces are nothing more than a way to group data stores. The main purpose of which is to avoid datastore and feature type name clashes.

Each "map" will have its own capabilities document. A map being just a container for layers, each layer being backed by a resource.

I agree that the terminology is confusing. I would be open to better names.

In 2.0 we basically just decided that 'namespaces' (particularly namespace prefixes) are equivalent to 'workspaces'. I think this is trying to squeeze too many concepts in to one. We generally want namespace prefixes to be pretty short, ideally 3-4 characters. But we have no good way of hinting to people that they should probably use shorter names for their workspaces.

This was done purely to maintain backwards compatibility. Without this assumption we would not really be able to have the concept of a workspace in 2.0, and i thought the middleground for now with the assumption would be a more gradual upgrade path that just introducing the workspace concept for 2.1. Perhaps not.

What I'd like to propose is that a 'workspace' consist of three things:
* A title
* A short name
* A URI

The title is used in the UI, and also in capabilities reporting on service information.

The short name is used for the namespace prefix, and in the url, like in the rest API.

The URI is for the namespace, what the prefix points to. If people don't fill it out we'll default it to like http://geoserver.org/shortname or something.

The short name will have a character limit (I'd say 5 or 6), and if the title is not filled out then short name will just be used.

What do people think? I'm not saying we need to get it in 2.0.x, but it's worth thinking about.

A title and short name sure, but URI I don't agree. A workspace in any way being associated with a namespace URI is just a short term hack. I don't think we want to introduce this concept for the long term.

I bring it up because I think we're trying to squeeze too much in to the 'workspace'.

The "squeeze" is temporary. Once namespace moves to just an attribute of a layer, and not a container for data the notion of a workspace becomes quite simple, it is just a folder more or less.

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

3

Chris Holmes wrote:

The short name is used for the namespace prefix, and in the url, like in the rest API.
The URI is for the namespace, what the prefix points to.

Future developments of application schema support will likely autoconfigure multiple namespaces (and their prefixes) found in collections of XML Schemas. Furthermore, we already have feature types that have properties from multiple namespaces. For app-schema, it is not useful to make any link between namespaces and workspaces when the data sources contained by a workspace are associated with many namespaces and feature types. They just get in the way.

What are workspaces mean to achieve? Will we have separate service URLs for each?

Kind regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

4

Hi Ben:

My understanding from talking to Justin last week was that workspaces
are simple folders for grouping datastores (nothing more).

Jody

On Tue, Jun 30, 2009 at 5:16 PM, Ben
Caradoc-Davies<Ben.Caradoc-Davies@anonymised.com> wrote:

Chris Holmes wrote:

The short name is used for the namespace prefix, and in the url, like in
the rest API.
The URI is for the namespace, what the prefix points to.

Future developments of application schema support will likely
autoconfigure multiple namespaces (and their prefixes) found in
collections of XML Schemas. Furthermore, we already have feature types
that have properties from multiple namespaces. For app-schema, it is not
useful to make any link between namespaces and workspaces when the data
sources contained by a workspace are associated with many namespaces and
feature types. They just get in the way.

What are workspaces mean to achieve? Will we have separate service URLs
for each?

Kind regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

------------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

5

Jody Garnett wrote:

My understanding from talking to Justin last week was that workspaces
are simple folders for grouping datastores (nothing more).

I think that is the aspirational target; this is not now the case. If workspaces become a content-neutral grouping mechanism, I will be happy.

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

6

I know we mentioned it in person; but it is worth repeating on the list.

Justin has been doing an excellent job of migrating geoserver
configuration (and configuration model such as workspace here) into a
sensible state. I really appricate his careful; diligent approach on
this one allowing GeoServer to read and upgrade "old" configurations
etc...

It is work like this that keeps GeoServer from turning into a series
of rewrites like some of our compitition.

Jody

On Wed, Jul 1, 2009 at 2:08 PM, Ben
Caradoc-Davies<Ben.Caradoc-Davies@anonymised.com> wrote:

Jody Garnett wrote:

My understanding from talking to Justin last week was that workspaces
are simple folders for grouping datastores (nothing more).

I think that is the aspirational target; this is not now the case. If
workspaces become a content-neutral grouping mechanism, I will be happy.

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia