hi @nacx, thanks for the suggestions. A couple of thoughts/questions: - Would the `Supplier<List<SecurityGroup>>` be a singleton similar to [FindSecurityGroupWithNameAndReturnTrue](https://github.com/jclouds/jclouds/blob/rel/jclouds-2.0.0/apis/openstack-nova/src/main/java/org/jclouds/openstack/nova/v2_0/predicates/FindSecurityGroupWithNameAndReturnTrue.java#L52-L55) - I assume it would have to inject the `NovaApi` in the same way? - I'm not familiar with the memoizing as used in jclouds, but I did think about some sort of memo/cache for this; however, I wondered if that would be right for this scenario. does it cope with the need to invalidate the memo when mutating operations are performed? e.g. if I add a group A, then another, B, then add an ingress rule to B permitting access from A, each of these three operations modifies the set of security groups that is defined, so each will require a fresh fetch of the list of groups. If the list is cached per ‘session’ (not sure what that is) then the sequence above won’t work. - I guess we could add accessors to support keeping the memo up-to-date on the fly as operations were carried out, but (a) I have bad experiences in the past with trying to keep caches in-sync with their back-ends, and (b) in any case I don't think that applies here, as in my example, the back end cloud will generate the ID for group A when it gets created, so the only way to get its value into the memo is to do the fetch again, so the memo isn't saving you an operation. For this reason I thought it might be safest to stick with doing a single `list` operation prior to each of the actions above.
I shall try to read up in the code on how the memoizers are used, and maybe we can work out together what to do. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/1059#issuecomment-277966551
