> * @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);
> and leave the options approach for things that are really supported in the > api. I sounds like a challenging trade-off: do you want to provide a consistent way of working with the API to the user, or do you expect the user of jclouds to understand that the options pattern only applies to options support _by the provider API_, and that any other "rich logic" (such as we are adding here) is thus "not allowed" to use options. No firm opinion on the subject though, so if you prefer to leave options out of this one, fine be me ;-) A different point: are we actually getting back different data from the concurrent call (i.e. more details?), or is it the same call as the other one, just executed more efficiently? --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-chef/pull/47/files#r15115859
