>* adding concurrent actions to jclouds here seems to go rather against the >direction we're talking elsewhere, where async stuff is being removed and the >recommendation is for users to do the async in client code * if we feel parallelism is essential as a speedup here, why are we even keeping the old methods?
Agree. as a first approach to allow removing the jclouds executors, the strategies were refactored to allow a custom executor in their interface. This would facilitate migration while keeping the current behavior. This is something that could be easily implemented in the client side, so having this in mind, what do you thing about marking the methods that accept an executor as deprecated, and remove them in 2.0? --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-chef/pull/47#issuecomment-49441591
