Hi,
reading GSIP73 and commenting as I go.
There is one sentence that is tripping me off a bit:
" Which basically means that in order for a layer group to be local to
a workspace, all the layers and styles it contains must local to the
same workspace, or global."
Can layers be global? As far as I know, they are not?
About styles, that sounds more reasonable tough, a workspace local
layer group can
only reference both a local style and a global one.
Besides that, at the proposal level there is a second thing that is
raising my interest, and it's
the changes to the security subsystem.
Now, I know workspace local is leveraging the security subsystem to
setup workspace local
catalogs, but the ResourceAccessManager interface is meant for
security and it's also
implemented by some external projects (GeoRepository, GeoShield, GeoNode)
for the primary purpose it was meant for.
The first obvious question is, is it ok to break the interface? Since
we are on trunk,
I guess it is, althought I'm starting to wonder if we should turn it
into an abstract base
class (e.g., are we done with the changes or will we need more in the future?).
For example, I've heard complaints that the current setup makes the
security system
check each layer one by one during caps generation, slowing it down, so maybe in
the future we might want to extend the interface to allow batch layer checks
(tell me what do do with these 2000 layers in one shot).
Another thing is that so far layer group security was linked 1-1 to
the security of
layers inside them, actually right now the group is visible only if
all the layers
in it are also visible, probably something too restrictivce (we could have the
group be available if at least one of the layers is there, obviously
serving only
the part that is meant to be visible).
Yet, wondering if being explicit about layer groups could also mean that
a layer group could override the inner layers visibilty, so that the single
layer is not accessible stand alone, but only as part of a group.
Or if the security subsystem could have an opinion of what part of the layer
group is available, filtering its contents.
Long story short, if we are introducing a layer group level access control,
maybe it contents should also include what inner layers and styles should
be allowed?
(this also goes back to the abstract class, if we make ResourceAccessManager
a abstract class the default behavior could mimic the current one, make the
group available only if all the layers in it are).
I've also looked at the patch, observations about it:
- the checks about the layer group contents being in the same workspace as
the group does not extend to styles, it seems I could setup a layer group that
refers a style that is local to a different workspace (GUI probably disallows
that, but what abou REST config for example?)
- I don't see support for workspace local groups and styles in REST config.
Logically speaking, shouldn't these be new resources?
<worskpace>/layergroups
<workspace>/styles
One final note about the user interface: I see a profileration of workspace
dropdowns in the GUI, here and there.
I understand this is the result of adding workspace specific functionality
piecemeal, yet I'm wondering if the user experience would could be improved
by having a single top level dropdown instead,
up close to the GeoServer logo, that defines the current workspace (including
lack of worspace specification), and have the rest of the gui respond to
that context showing only what's local to the current 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
mob: +39 339 8844549
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
-------------------------------------------------------