I think constrained to the workspace / virtual service makes a lot more
sense. Indeed to me part of the workspaces is a place you'd apply security
settings. With security in mind it seems more logical in general to have
the scope be constrained. May not be hard to implement those security
contraints so they don't appear in global if you set the workspace private,
but having the scope constrained will just have it make more sense to a
user imho.
As for resource file names, I think in general it does make sense to track
things more, and that we can probably do some nicer stuff with exposing
them more easily to the web if we do track them.
my $.02
On Wed, Jan 4, 2012 at 7:07 PM, Justin Deoliveira <[email protected]>wrote:
> Hi all,
>
> Following after the recent work to make workspaces in geoserver be able to
> live truly autonomously, i am back to revisit a topic that was brought up
> before, and that is storing styles on a workspace by workspace basis.
> Before I get to far with an implementation I wanted to run some ideas by
> folks first.
>
> First thing is style visibility. If styles can be stored globally and
> stored under a workspace, what styles should be visible from where? It
> would make sense that "global" styles be visible everywhere, whether you
> are going through a virtual service / workspace or not. But what about non
> global styles? Should they be constrained only to that workspace / virtual
> service? Or should you be able to access them globally as well, perhaps
> with some prefix?
>
> I am thinking the former. To illustrate, here are some examples:
>
> Consider some global styles:
>
> * point
> * line
>
> And some local ones:
>
> topp:
>
> * foo
>
> nurc:
>
> * bar
>
> The following requests would all be valid:
>
> geoserver/wms?...&styles=point
> geoserver/topp/wms?...&styles=line
> geoserver/topp/wms?...&styles=foo
> geoserver/nurc/wms?...&styles=bar
>
> The following requests would not be valid:
>
> geoserver/wms?...&styles=foo
> geoserver/wms?...&styles=bar
> geoserver/topp/wms?...&styles=bar
> geoserver/nurc/wms?...&styles=foo
>
> Thoughts?
>
> A second issue i ran into are styles that make use of other resources
> (like external graphics), that are stored along side the sld file. If we
> make styles be able to be part of a workspace, this means the style sld
> file can potentially move around, and for that to work we have to move not
> only the sld, but any other resources it requires. Currently our config
> model doesn't specify any of these files.
>
> One potential solution is to add an additional property to StyleInfo,
> something like "resourceFilenames".
>
> StyleInfo {
> List<String> getResourceFilenames():
> }
>
> Which would store any supplementary files that are needed by the SLD. When
> the user uploads a new file via the ui, we examine the file and look for
> any external graphics that point to relative file uris, and detect the
> additional resources. This might not be bullet proof so I was also thinking
> of an additional form field (a list chooser with add/remove) that would
> allow the admin to explicitly specify the supplementary fies.
>
> Thoughts?
>
> Thanks folks. Feedback much appreciated.
>
> -Justin
>
> --
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.
>
>
>
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Geoserver-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
