StorageClient

Question

MS has provided the StorageClient project as an example project to call the Azure APIs.  Does MS plan for developers to use this class as a supported or maintained way to get to Azure?  Will it be updated as necessary throughout the beta process by MS?  If not the StorageClient, will there be something else?  I'm not looking for the StorageClient to do everything, but I do need some high level way to access Azure.  If there is not highlevel API, preferably .NET, to get at Azure, this may slow adoption until someone produces a highlevel API to access Azure.  The last thing I want to do is spend time writing lowlevel rest "stuff."

The next question, is someone writing a .NET API for accessing azure outside of MS?

Wally

---

MVP in ASP.NET - ASPInsider - Author

Answer 1

Hello, while I can't 100% assure you at this time, we're working on high level .NET wrappers (and wrappers for other platforms). You can think the StorageClient library as the first step. Today it doesn't provide all features the REST APIs give you (such as upload a single block), and maybe you'll discover several bugs, and you must expect a lot of break changes in the future (this is CTP). But for most scenarios, the features it provides should be sufficient. Finally, if you have further requirements, you can modify the source code. Anyway, personally I think even if the StorageClient is sufficient for your scenario, you still need to work with the REST APIs directly in some test applications, if it's only for learning purpose...

---

Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.

Answer 2

Wally,

MSFT's party line on StorageClient doesn't make much sense to me. They want .NET developers to write Azure applications but won't commit to a final version of StorageClient being an official, supported API for Azure Data Services. Currently the central committee's line is that the REST protocol is the only "official" API and "We are not ready to announce any future plans with respect to any official library."

See the end of Azure Storage Services - StorageClient Library: Blob Storage API Class Reference for links to other similar vagaries.

Bob Muglia says in Q&A with Microsoft's Bob Muglia of 1/6/2009:

"The problem is the talent to build [Azure services] is very limited. A typical IT manager doesn't have the capability, and a typical development staff doesn't have the capability to do it ... Our goal with Azure and Visual Studio together is to take and infuse an application model with something that the average developer can use to build exploitive applications."

The "typical development staff" isn't likely to be able to quickly or economically exploit Azure features like "blocks, conditional uploads (based on date), asynchronous calls, etc." or "use the parallel block upload and asynchronous calls to maximize the throughput at cost of complexity and higher memory usage."

Guess it's time to write a post about the need for better support of .NET cloud developers.

--rj

---

OakLeaf Blog

Answer 3

Let me try to clarify some of the statements. When I said the StorageClient is not optimized for performance/robust services I meant to say that we do not take responsibility that the implementation of the library is the best for perf/robustness. For example, we may use operations that catch/throw exception in critical paths for simpler implementation. The idea is that the library is an implementation sample rather than official library for the service. This also means we could modify the APIs to be a better sample, as we do not promise any backwards compatibility in the sample library. (ie. We can change the default RetryPolicy to be Exponential backoff, rename APIs, add/remove parameters, etc.)

On the other hand, the REST apis are considered official APIs, whch means that we will try to keep the APIs backwards compatible. (This also means that older versions of StorageClient should continue to work as they work against REST)

I'm sorry if my message implied we have no plans to provide a "comprehensive library" - all I meant to say is that StorageClient is not to be considered that library at this time.

Answer 4

It's been 10 months and the adoption is going larger however I somewhat expected some 3rd party controls to begin to show.  I agree with the other comments and have looked at the StorageClient as a possible Azure solution for my soon-to-be enterprise app.  The only problem is I would rather have a more mature solution by now.  When I look at that compared to NSoftware's solution for adapting .Net applications to Amazon's S3 service...I think the NSoftware is more enterprise ready.  I would really like to see some (yes, some will hate the term) drag-and-drop capabilities for Azure in which much of the plumbing for REST calls are done for me.
I'm still plugging away and will probably test-bed StorageClient since wide-spread use will probably not happen soon in the case of my application.  In the event it doesn't work to expectations, I will have the NSoftware/S3 option and quickly migrate to it.

Answer 5

Hi,

Please take a look at CloudStorage.API project on CodePlex: http://cloudstorageapi.codeplex.com/. From what I understand, this provides another way of programmatically manage your Azure Storage.

Hope this helps.

Thanks

Gaurav Mantri
Cerebrata Software
http://www.cerebrata.com/Products/CloudStorageStudio/Default.aspx