Hi Andrea,
Thanks again for taking the time to provide feedback on these proposals
over your weekend. Comments inline.
On Sun, Feb 26, 2012 at 8:07 AM, Andrea Aime
<[email protected]>wrote:
> 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.
>
> Right, the comment about layer groups being local/global makes no sense. I
will change that text to make that clearer.
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).
>
> Yeah, agreed this seems a bit off. Actually the current patch uploaded is
not the complete patch, sorry i forgot to upload the new patch (too many
proposals to manage) i had to add a secondary catalog
wrapper specifically for local workspace stuff. I would be happy to move
things into there rather than play with ResourceAccessManager, this would
remove the additional fo the style and layer group access limits.
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?
>
Yeah, I thought about this as well, and while I like the idea didn't have
time to experiment with implementing it. Basically since the whole system
is built upon hiding portions of the catalog it seemed tricky to detect the
layer group cases to avoid doing this. Although with a dedicated local
workspace catalog this could be easier to pull off now.
(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).
>
+1 on an abstract class.
>
> 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
>
Yeah, restconfig has yet to be updated. Realized this late last week and so
it is on the table and i plan to add it before the proposal is accepted.
>
> 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?
>
Yeah, this is what i had envisioned originally as well, but as you mention
adding things piece meal makes it hard to this sort of thing. Quite a bit
of work though. There would also be the question of how to make it possible
to move entities among workspaces.
Anyways, +1 on a ui redesign around the local workspace stuff but it
represents quite a bit of work, not sure i wil be able to fit it in to this
round of work. Any chance we can push this off as a future improvement?
>
> 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
>
> -------------------------------------------------------
>
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Geoserver-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
