Jacob Henner

I'm not sure I still agree with the change proposed originally. I'm going to think about it some more, and will update this issue once I have a better idea...

I'll try to look at these three issues tomorrow. > We can use the resource version as you suggest and implement the list-and-watch pattern but the question is if we...

So after conducting some more research[1], it seems as if the client-go library maintains a distinction between watches and informers. The former is the low-level operation, the latter is a...

I've written a small proof-of-concept informer-like wrapper. I have to finish adding some features and testing the implementation before sharing, but perhaps it'd be useful here. So far it has...

So far I've implemented an informer-like wrapper which handles 410 Gone reconnections, bookmarking, and basic event-handling. I'm still working to figure out how closely to align it with the Informer...

Didn't have as much time as I hoped to work on this over the week. Will send something over once ready. My initial implementation has been focused on increasing reliability...

Apologies for not providing an implementation sooner, my priorities have changed and I haven't had much time to work on this. I've published an initial implementation of my idea in...

It looks like this behavior was introduced in https://github.com/tomplus/kubernetes_asyncio/commit/61852ea42d4ec562d61cbe86d391e5de8a88e75c, as part of https://github.com/tomplus/kubernetes_asyncio/pull/22. @olitheolix, could you clarify why the asyncio watcher should stop if the server has responded with an...

> The function should only deal with the current event stream and return once K8s closed that stream. The caller can then implement the desired retry/reconnect/whatever logic itself. Ah, I...

> I got it, the official client "ignore" empty lines. In my opinion it's better if a library does mandatory retries to simplify end-client's code. Should I adjust the tests...