Jody,

On 07/24/2015 10:28 PM, Jody Garnett wrote:
Still we may be thinking in a different direction. The initial import from data directory to JDBCConfig is a one time journey. After that the idea is to manage via REST API (yes ResourceStore still needs a REST API).

It sounds like you are considering editing files on disk, and then reimporting them as they change? That is a very tricky problem since the data directory would then be a local cache *and* and place for editing.

Well this was something Kevin suggested that was considered before. That's why I was saying we need to get away from the use of file(), of course we want people to use the DB directly. Without this, we will definitely need to change any code that writes configuration to a file, because that will not be saved then.


   
https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/security/file/FileWatcher.java

   Have a look at the above, it is used by security system to "watch"
   for configuration changes.


I am aware of it, I was looking into it for the reason above. I'm just not sure why you thought I wanted to replace it. This is why we should continue this on a chat, miscommunications... ;)

I don't completely agree, we have a few sections of the code that require file(). See the initial design doc for details (it was one of templating things (GeoServerTeamplateLoader?) and perhaps Fonts in the styles directory.

Since dir() is a short cut for going through list() and calling file() it would remain undeprecated.

Okay, understood. Fair enough, as long as they are not used to write data, and preferably not when not necessary but you agree with that.

You know resource.dir() acts like find or create a directory right? It will make the directory if needed ...
Yes I know, but again, I was talking about creating a directory in the store (which may or may not be a FS or a DB) and not on the FS.

Anyway, let's finish this on chat.

Regards
Niels
------------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Reply via email to