With regard to the resource file name, maybe it would be better to provide
some tools for verifying the resources for a style (ie, don't persist the
file list, don't automatically move image files around, just add a
'Validate Resource References' button on the style editor page.)
--
David Winslow
OpenGeo - http://opengeo.org/
On Thu, Jan 5, 2012 at 9:56 AM, Chris Holmes <[email protected]> wrote:
> 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
>
>
------------------------------------------------------------------------------
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
