*sigh*... I think leaving it hardcoded is not acceptable. [Your requirement](http://markmail.org/message/4b2ebsyelfsa4rpk) was to support both, and you explicitly said:

>The two service types that need to be supported in the CloudFilesApi are
"object-storage" and "rax:object-cdn"

So leaving the service type hardcoded **does not** meet the requirements. If we want to support both, we must allow the user to configure the service type. There are two good ways of doing this:

* Dynamically when you get the CDNApi.
* Configuring the service type when creating the context.

The first approach can be done by changing the api factory method to receive the service type too:

```java
CDNApi api = cloudFilesApi.cdnApiInRegionAndServiceType(region, serviceType);
```

The implementation details were detailed in [my answer to your requirements](http://markmail.org/message/d6knfqeyoslmuyk6). This approach **would not require** users to create a different contact for each service type.

We also talked about this in the IRC, and you discarded this approach as you didn't like passing that second parameter to the method, so the remaining approach was configuring the service type when creating the context. After explaining it, during several days, in the IRC, you agreed it was a good approach.

So my question is… What has changed?

* If you don't want to tie the service type to the context, go for the first approach and let users to pass the service type at runtime.
* Otherwise, you can go for the context approach.

But leaving the service type hardcoded **does not meet the requirements**, and makes all discussions we had on the mailing lists and the IRC have no sense :)

Seriously, has the requirement to support multiple service types changed?