On Tue, Feb 25, 2014 at 1:22 AM, Jody Garnett <jody.garnett@anonymised.com>wrote:
Thanks for wait - proposal is now ready:
http://geoserver.org/display/GEOS/GSIP+106+-+Managed+File+API
The proposal consists of a "ResourceStore" API for streaming based access
to resources and a plan to transition the codebase.
I am quite happy with how the interfaces have turned out. You can evaluate
for yourself here:
- https://github.com/boundlessgeo/geoserver/tree/resource_store
I did dig a bit deeper. Here are some observations.
Your question in the proposal "Is it worth scanning SLD files to determine
icons used?". Yes, I believe it is, but do not
expect it to always work, as people can use dynamic symbolizers and embed
cql expressions in the paths, in that
case, there might be a need for some way to tell GeoServer which
directories/files should be managed manually in order
for a cluster using JDBCConfig to produce proper maps on all nodes:
http://blog.geoserver.org/2008/12/08/dynamic-symbolizers-part-1/
About Ians feedback to "Consider implementing Atomic-File-Write (use file
lock, write to separate file and rename into place)",
good idea, but mind that while some NFS implementations work well, others
do not in terms of locking, so I'd suggest
to roll a LockManager interface like GWC has, and allow for other non NIO
lock based implementations to be plugged in
(e.g., a Hazelcast based one)
About http://geoserver.org/display/GEOS/ResourceStore+Design, "solutions
not based on xstream" is not
quite correct, it's more solutions that are not storing configurations in
catalog and service objects.
For example, the ogr output format module uses xstream for persistence, but
in a custom file that's outside
of the core loader clasess.
About the GeoServerResourceLoader changes, is this enum a implementation
debugging aid, or
are we going to have it long term?
/** Mode used during transition to Resource use to verify functionality
*/
private enum Compatibility {
/** Supplied ResourceStore used for file access */
RESOURCE,
/** Use search locations to locate file */
SEARCH,
/** File and Resource Logic compared, exception if inconsistent. */
STRICT };
Also, it seems GeoServerResourceLoader is not really having the
ResourceStore injected
like the doc say, I assume that still needs to be developed right?
(by the looks of it, the branch seems a proof of concept, but wanted to
make sure)
I haven't had a detailed check at the rest of the code, but overall it
seems good, +1
on the proposal
Btw, you are going to create some support/replacement for the property file
watchers yes? 
Think about someone changing the control flow config on a node, your code
notices
thanks to the resource API, the file gets saved in the database, and then
you said
the slave will get the file checked out automatically when trying to access
it, but
one thing needs to be maintained, the watches make sure we don't hit the
file system
too often, no more than once a second, because that's a major drag if we do
it 100
times a second or more, so we'll need something that also avoids checking
the
database 100 times a second (as that might be even slower than checking
the last modified time on the file system).
Cheers
Andrea
--
== Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information ==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------