> +
> +import com.google.common.base.Function;
> +import com.google.common.base.Supplier;
> +
> +/**
> + * @author Jeremy Daggett
> + */
> +@Singleton
> +public class RegionToCDNEndpoint implements Function<Object, URI> {
> +
> + private final Supplier<Map<String, Supplier<URI>>> endpointsSupplier;
> +
> + @Inject
> + public RegionToCDNEndpoint(@ApiVersion final String apiVersion, final
> RegionIdToURISupplier.Factory factory) {
> + this.endpointsSupplier =
> factory.createForApiTypeAndVersion(ServiceType.OBJECT_CDN, apiVersion);
> + }
@jdaggett I completely understand that having to create two contexts is not
ideal. Let's put things in order, so we can pick the right approach:
The requirement is to support "object-storage" and "rax:object-cdn" (and no
other service types). In order to support both, you have to let the users
choose the service type they want to use somehow. I can only think about three
ways to do this:
* Allowing to dynamically specify it at runtime. To do this, the factory method
should be modified [as I explained in the original
email](http://markmail.org/message/d6knfqeyoslmuyk6). It would look like this:
```java
CDNApi api = cloudFilesApi.cdnApiInRegionAndServiceType(region, serviceType);
```
* If configuration has to be dynamic, but can't be a parameter, then it must be
done "somewhere" in the execution environment (that is, the context). This is
the approach discussed in this PR.
* If you don't want to pass the service type parameter dynamically and also
don't want to configure it in the context, you could have two factory methods,
one for each service type:
```java
CDNApi api = cloudFilesApi.cdnApiInRegionForObjectStorage(region);
CDNApi api = cloudFilesApi.cdnApiInRegionForRaxCDN(region);
```
In approach 1 and 2, a validation could be performed and failure would happen
at runtime (which is not ideal), and in the third approach, you have one method
for each service type, which seems confusing. All three approaches have pros
and cons, but all three **meet the requirements**. Personally, I'd go for
approach 1, and pass the service type tot he factory method, as I suggested in
the initial email.
I think we shouldn't hardcode it, as it **would not meet the requirements to
support both**. IMHO it is worse to leave the PR as-is, leaving users without
the possibility to use "object-storage", than implementing one of the three
suggested approaches.
Furthermore, if we merge this as-is, how long will it take until we support the
"object-storage" service type? Can we put a date on that?
IMHO if we know, right now, that the PR does not meet the requirements, and
already know three approaches that could fix that (with their pros and cons),
we should go for one of them now, otherwise we are just introducing more
(unnecessary) technical debt to the project.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/79/files#r10143888
