+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
Title: Message Title
Tom Ruff created an
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
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...
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
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
>
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
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.
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 -
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
Title: Message Title
Jeroen Dries created
11 matches
Mail list logo