implement Copy for Client?

[clux]

we always clone this for passing between threads/informers anyway so might as well hide the clone call

[clux]

This isn't that big of an issue now that Informer's and Reflector's use Resource internally.

While reqwest::Client only clones the handles to the internal client, we do still clone a bunch of configuration. Perhaps it's best to not hide any magic like this.

[clux]

A quick grep through examples/ directory reveal 22 clones, 15 of which is the client, and the other mainly due to k8s-openapi being lax with Option. If our API requires that much cloning for just the simplest examples, then it will be quite distracting in real situations.

Saw tons of distracting clones today caused by our api in h2o mostly like this:

• https://github.com/h2oai/h2o-kubernetes/blob/b11cd2862a52b3634fba1ea443f0e340f91a4f2d/operator/src/controller.rs#L182-L185

I think maybe we should rethink this. As it stands people are forced to think about whether to duplicate a Config, along with various Strings, Urls, for every Api needed, or for or parallel application.

Generally, I think, the small amount of memory this uses is not really a huge concern, it should be quickly reclaimed, and not likely to cause a bottleneck for a controller. BUT; it's an awkward thing to present in the api.

We could hide all this (everything's private anyway) in an Arc'd inner like reqwest does, and derive Copy

[nightkr]

You can't implement Copy if you have a custom Clone::clone (as Arc does).

[nightkr]

Closing this as infeasible.