+1, better indeed to start with a smaller scope.
On Thu, Mar 23, 2023 at 1:55 PM Roar Brænden
wrote:
> Hi,
>
> I understand that this suggestion is more involved in GeoServer codebase
> than GeoTools.
> And I also understand you want to keep a narrow scope.
>
> But it brings on some interesting
Hi,
I understand that this suggestion is more involved in GeoServer codebase than
GeoTools.
And I also understand you want to keep a narrow scope.
But it brings on some interesting thoughts. What about MonitoringHTTPClient?
Hilsen Roar
> 23. mar. 2023 kl. 10:50 skrev Andrea Aime :
>
> HI R
HI Roar,
for the first round of implementation, I have no place that's actually
using the GeoTools HTTPClient interface.
Given this would be a wrapper, it does not seem much of a HTTPBehavior, but
more of a hint, where the hint
value would be the URLChecker to use.
Generally speaking, I'd expect i
Hi,
Ok, got that.
Regards, Roar
> 23. mar. 2023 kl. 00:09 skrev Jody Garnett :
>
> Roar:
>
> I was mostly interested in clarifying the api; I just had an experience with
> enabling/disabling resources for different layers that had a similar OR test
> where any true was sufficient - and it wa
Roar:
I was mostly interested in clarifying the api; I just had an experience
with enabling/disabling resources for different layers that had a similar
OR test where any true was sufficient - and it was very confusing.
I do think that when this is ready it can be applied to geotools codebase
as a
Hi,
This looks like something I've been thinking about. Would love to implement
such a solution. Too bad I'm not in a position to do so.
Could that blocking, you wanted Jody, be handled by throwing an exception?
Should this involve an addition to the HTTPClient interface as well? How to
react
