> * @return The details of all existing nodes. > */ > Iterable<? extends Node> listNodes(); > > /** > + * Lists the details of all existing nodes, executing concurrently using > the executorService. > + * > + * @return The details of all existing nodes. > + */ > + Iterable<? extends Node> listNodesConcurrently(ExecutorService > executorService);
There are already things the end users must know about jclouds-chef: when should they use the ChefService or the ChefApi? There's no easy way to implement that "rich list" operation directly in the Chef API (response parsers or transformers, which are the current mechanisms jclouds provides don't seem appropriate to me), and that's why it was initially implemented in the ChefService, but that means users already have to know what class to use. This is not ideal, but having said this, I like your proposed approach. Not because it encapsulates the use of an executor in a more generic options class, but because it will allow us to cleanup the ChefService interface. I think executors as a parameter are OK for the strategies (they are specific implementations of something), but getting rid of them in the ChefService seems like a good idea. The problem is that it is a breaker change. If we're going to remove the methods in the next release, is it worth the change? --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-chef/pull/47/files#r15116597
