David Radley

@MarekMaj thanks for making this change - it works for 2 of the releases bu not for 1.18.1, where I now see the CI fail with error ``` Run madrapps/[email protected]...

@kristoffSC @MarekMaj hope to get to this this week. Thanks for your feedback.

@Raz0r See [https://github.com/getindata/flink-http-connector/pull/94](https://github.com/getindata/flink-http-connector/pull/94). As part of introducing caching there is a max-retries option that can be used

@kristoffSC we are interested in having caching. I was thinking the change would be quite minimal to the http client code base. I was thinking of a very similar approach...

@kristoffSC sounds good. I am glad to be able to do more with this connector. I had used the connector with Flink 1.18 for our use cases in the past....

@kristoffSC I have not yet got to it. But still intend to!

@kristoffSC I have had a look at this - it is not as simple as I had thought. It seems that the HttpClientLookupFunction does not extend LookupFunction. LookupFunction has its...

@kristoffSC any thoughts on this one. If not I will attempt a refactor to use the Flink caching framework.

@ChenShuai1981 the lookup support that exists currently ends up issuing gets, puts or posts on single records. For the scan to work, I suspect we would need to issue searches,...

I am prototyping adding scan support. The reason I think this is useful is that: - this will make this connector more comprehensive - so could realistically be contributed to...