Re: [Geoserver-devel] GSIP-137 ResourceStore REST API Proposal

2016-02-02 Thread Ben Caradoc-Davies
+1. Looking pretty good. Observations: - Instead of metadata, it would be (arguably) more RESTful to support a HEAD operation. You have a header for Last-Modified, could add an X-Parent and X-Type, and name could be deduced from the URL. Or is the need for custom HTTP headers a red flag? (Not

[Geoserver-devel] [JIRA] (GEOS-7397) NODATA value not used for fill in reprojected tif

2016-02-02 Thread Tom Ruff (JIRA)
Title: Message Title Tom Ruff created an

Re: [Geoserver-devel] GSIP-136 Resource Notification Dispatcher

2016-02-02 Thread Andrea Aime
Ops, yes, of course! +1 Cheers Andrea On Tue, Feb 2, 2016 at 10:43 AM, Niels Charlier wrote: > So, if that has been fixed does that mean we can get an additional +1? > > :) > > > On 31-01-16 19:18, Jody Garnett wrote: > > Right, I can delete the "listen to root" idea. I had

Re: [Geoserver-devel] GSIP-137 ResourceStore REST API Proposal

2016-02-02 Thread Niels Charlier
On 30-01-16 12:08, Andrea Aime wrote: The ResourceMetadata xml representation should be follow the same resource interlinking approach as our main REST API, for example: Modified. I'd remove POST, two ways to do exactly the same things seem redundant to me, not sure what other think...

Re: [Geoserver-devel] Proposal: ResourceStore Rest API

2016-02-02 Thread Niels Charlier
In firefox - and I expect other browsers as well - this doesn't seem to be a problem, even without mime it is smart enough to know itself (from the extension probably). Regards Niels On 27-01-16 17:04, Jody Garnett wrote: Good research, you may be able to make a guess at content type based

Re: [Geoserver-devel] GSIP-137 ResourceStore REST API Proposal

2016-02-02 Thread Andrea Aime
On Tue, Feb 2, 2016 at 11:26 AM, Niels Charlier wrote: > Writing the above I actually raised one more question: what happens if > someone > goes and chances configuration files using the resource REST api? > It's ok to say "it's store implementation dependent", but at least we >

Re: [Geoserver-devel] GSIP-137 ResourceStore REST API Proposal

2016-02-02 Thread Niels Charlier
Hmmm, I still find it difficult to understand your point. If you are using JDBCConfig, the catalog .xml files become meaningless, are ignored and changing them never has any effect. There is no difference there whether you are using jdbcstore or not. As far as I see it, changing a config

Re: [Geoserver-devel] GSIP-136 Resource Notification Dispatcher

2016-02-02 Thread Niels Charlier
So, if that has been fixed does that mean we can get an additional +1? :) On 31-01-16 19:18, Jody Garnett wrote: Right, I can delete the "listen to root" idea. I had the idea that we could listen to the root folder (as an alternative to this proposal) and be advised of all resource changes.

Re: [Geoserver-devel] GSIP-137 ResourceStore REST API Proposal

2016-02-02 Thread Jody Garnett
Geoserver will kind of notice in both cases - icons are cached so will not pick up on a change unless we add a watcher (or until as you say the next reload). Things like security that already have a watcher will be noticed in both cases. We should put this off until we look at notification -

Re: [Geoserver-devel] GSIP-137 ResourceStore REST API Proposal

2016-02-02 Thread Andrea Aime
On Tue, Feb 2, 2016 at 11:54 AM, Niels Charlier wrote: > Hmmm, I still find it difficult to understand your point. > > If you are using JDBCConfig, the catalog .xml files become meaningless, > are ignored and changing them never has any effect. There is no difference > there

[Geoserver-devel] [JIRA] (GEOS-7396) ClassCastException with WrappedSampleDimension

2016-02-02 Thread Jeroen Dries (JIRA)
Title: Message Title Jeroen Dries created