Some stupid questions, apologize but I do not have much time to see deeply
the implementation proposal ... basically if I understood correctly this
resource store write the file into the data dir streamed out from the DB if
it does not exist, is that right?
The proposal is actually just focused on the introduction of
the ResourceStore API (since this will involve an application wide refactor
similar to when we updated FeatureCollection).
Separately the JDBC Config module is going to implement ResourceStore
backed by a database - in the fashion you describe. If the code asks for a
file it will be written out to the data directory. If the code only asks
for an input stream we may be able to provide that right from the database.
In that case I see that you already spoken and taken into account the
> locking mechanism.
>
The email discussion has a resulted in a couple additions for the
FileSystemResourceStore implementation: file watcher functionality, file
lock and "atomic file write".
Please correct me if I'm wrong, as I said I did not have the chance to
> study the examples.
>
I will be looking at file lock and file watching next, so you have not
missed anything yet.
------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
