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 ------------------------------------------------------- ------------------------------------------------------------------------------ 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
