Thanks for the discussion Andrea, comments inline ...
--
Jody Garnett
On 24 March 2015 at 00:24, Andrea Aime <[email protected]> wrote:
> An idea I would like to float (and can write up a proposal if we like it)
>> is to allow an administrator to define additional data locations and assign
>> them a variable name we can use in a data URL.
>>
>
> We actually had that for a long time with the multiple resource loaders
> (we just lacked the support for a variable based one) but... didn'nt you
> kill that support with the resource store work?
>
I did, the facility was not being used (perhaps additional resource loaders
could be configured as part of the application context?)
> * ${shared}/annual/zones.shp - example of a customer shared data location
>> defined by admin
>>
>
> Where would this variable be set? 1), 2), 3) as above, or somewhere in the
> GeoServer global settings?
>
I was thinking somewhere in 1) 2) 3) above - as my concern was
configuration portability (the usual story of taking a configuration
between test and production environments). I guess the Java EE happy way to
do this would be to define the path as a JNDI lookup (much like switching
between test and production databases).
I can see how for nodes on a cluster defining as a GeoServer global setting
would be appropriate.
If they can be changed while GeoServer is running we have to consider it at
> the ResourcePool level, all stores using them
> must be disposed of.
>
Agreed. Right now I just watch all the data stores fail and get disabled
when moving content on disk.
> * ${workspace}/data - the default location for data upload, the builtin
>> variable workspace allows for stable URLs when workspace renamed
>>
>
> So if you rename the workspace there is going to be some procedure that
> moves all the files in that folder to the new one?
>
Yes. Same deal for workspace styles/icons.
> Or are you going to invalidate all stores pointing to that variable on
> rename?
>
I would like to carefully move the files on disk and kick ResourcePool
appropriately.
(Personally my preference is to store large datasets outside of the data
directory, this ${workspace} idea is a nod to those who like keeping
everything in the data directory and run into trouble when a workspace is
renamed.
> Plus, it would seem to me that ${workspace} needs to be relative to
> something else too, like, I would probably code it up
> as ${shared}/${workspace}.
>
I was thinking of listing it as a "top level" directory when browsing for
data - don't want this to be too complicated. Since workspace support files
are stored in the data directory, this would end up being a short cut for a
common (troubling) case :(
> I would also point out that for uploads, we already have a pluggable API
> in REST config that can be used to decide where to put the files, used for
> that very purpose:
>
> https://github.com/geoserver/geoserver/wiki/GSIP%20114%20-%20PathMapper%20extension%20point%20to%20control%20REST%20file%20upload%20locations
>
>
Yes, reviewing this as part of the resumable rest API proposal is part of
my inspiration.
> When using the file browser in addition to data directory, home and file
>> system the locations defined by the administrator can also be listed.
>>
>
> Hum.. .yeah, I guess in theory the browser should be smart enough to
> replace the variable when there is a path bit that
> uses them?
>
Or did you want to make it simpler, and just provide the variables as
> roots? Works best if a path can contain a single variable I guess...
>
Just listing them as roots (like data directory, home directory and file
system).
Cheers,
Jody
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
