amihaiemil
Remove SslHttpClient?
I would like to remove this class and all the code (constructors in RemoteDocker, mostly) that makes any assumption regarding securing communication with a remote Docker instance.
My reasoning is that we shouldn't make any assumptions since we will most likely not cover all the possibilities and we are just polluting the library. If the user really needs it and knows what they are doing, they can provide a properly configured HttpClient when instantiating a RemoteDocker.
What do you think?
@amihaiemil I agree that you should remove it. As you said, there are just too many options.
@amihaiemil I agree, I like your idea of a properly configured HttpClient if the user need some different behavior (like ssl). I'll let https://github.com/amihaiemil/docker-java-api/issues/177 on hold while you decide this.
@llorllale well, maybe the fact that we assume everything to be in a single keystore?
And then, simply the fact that we ask for the passwords doesn't seem right: if the user really knows what they want to do (and understand how we are going to use that data), then it will be easy for them to configure their own HttpClient. Furthermore, who knows, maybe they want to pass through a Proxy. It just seems like a lot of possibilities and our configuration seems to be lousy. Doesn't it seem the same to you? :D
And besides, even if they want to use us, they still have to configure the keystore and truststore + passwords, before passing everything to us. If they are not able to configure their own HttpClient it means they do not understand the topic and won't be able to do it anyway.
@amihaiemil I understand your concerns. I do think the specific issues you've pointed out can be addressed by improving the design though.
I personally still think providing users some basic pre-configured clients is useful. See if this example makes any sense to you.
@0crat out (here)
@amihaiemil Job gh:amihaiemil/docker-java-api#215 is not assigned, can't get performer