> * @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);
Never is late for a discussion to improve things, even if PRs are merged! :) I understand what you mean, but in this case it might be different. The Chef API does not return the entire objects in the list operations; it just returns the name, URL, and a few more fields. If you want to get the list of nodes (or any object) with all the information populated, you need to perform first a list operation and then a get one for each of the returned nodes. This is why this "rich list" functionality is implemented as separate strategies instead of being part of the ChefApi itself. The options approach applies usually to APIs that "understand" the options parametes and can perform filtering, pagination, etc, on the server side, but that's not the case of the Chef API. The way you get the list of nodes and how you get the details of each one is up to the client, and I think it makes sense to provide the methods that accept no parameters or an executor in the strategies, and leave the options approach for things that are really supported in the api. Does this make sense? (I also love this kind of design discussions :)). --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-chef/pull/47/files#r15115673
