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.

------------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Reply via email to