@nacx: Just some minor comments from me. As regards the question you and @adriancole have been discussing: I like the suggestion of saying "we'll configure safe stuff for the provider you choose, but if you want to make arbitrary other configuration changes to the HTTP client, here you go!"
This allows jclouds to get rid of the responsibility of correctly handling SSL configuration based on a provided SSLContext that effectively becomes a "config spec", and also allows for all kinds of other weird and wonderful HTTP client configurations that an API, provider or end user might need. As you say, though, SSLContext _is_ what is being used currently, so as long as we have an idea of how we want to do this "properly" going forward, I'd be OK with getting this in now as work-in-progress and then moving on to a different PR that moves to a different style of non-default HTTP client configuration. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/619#issuecomment-65006775
