Rackspace has developed a C# SDK for CloudFiles, which in turn is based on OpenStack Object Storage. As we’ve used this SDK, csharp-cloudfiles, we’ve encountered some unexpected “issues.” While we see these issues as flaws, some may consider them to be unintended consequences – we’re open to correction. Regardless, other developers may benefit from our comments here.
The first item has to do with UserCredentials’ constructors. com.mosso.cloudfiles.UserCredentials has four constructors:
public UserCredentials(string username, string api_access_key) // AVOID!
public UserCredentials(Uri authUrl, string username, string api_access_key)
public UserCredentials(Uri authUrl, string username, string api_access_key, string cloudversion, string accountname)
public UserCredentials(Uri authUrl, string username, string api_access_key, string cloudversion, string accountname, ProxyCredentials proxyCredentials)
Note that all except the first constructor take the authorization url as the first parameter (authUrl). It turns out that the authorization url is hard-coded in the first constructor, rendering it useless. This constructor uses https://api.mosso.com/auth (via Constants.MOSSO_AUTH_URL), so it’s only useful if you have valid authorization credentials for that end-point. Since (it seems) only Rackspace’s internal development team has valid credentials there, they should remove this constructor.
While on the topic it’s important to point out that the authorization url passed in actually becomes part of the UserCredentials’ member data. Code can retrieve the value from the AuthUrl property, but cannot set the value. As a matter of fact, all of UserCredentials’ properties are get-only (and their member data fields are readonly)! The only way to change any of the values is to construct a new UserCredentials.
Ok, so UserCredentials is no memory hog and creating multiples is unlikely in many applications. The issue is that this class seems to ignore the value of separate concerns. Why, for example, is proxyCredentials a member of this class? Are a user, account and authorization url always expected to have a single proxyCredentials? It seems to us that the endpoint, user credentials and proxy credentials need to be combined when calling down to the REST api, but should be separated for flexibility above that. We think several of these members should be independent, or at least more flexible by being settable.
What are your thoughts? We’d like to know; comment below.