Azure, Sync Framework and Access Control Service: Are there obvious shortcomings or problems in using this technologies together?

I have a desktop application which uses flat files (some xml and small pictures) as data. I want this data to be available on other PCs which have the desktop application installed and usable by a smartphone client (WP7 at the moment) as well.

The user should have it very easy to synchronize this data. He should be able to use accounts he already possesses (Live-Login, Googlemail, Facebook,...).

I thought about using Azure Blob Storage to save the data in Azure, the Sync Framework to perform the actual synchroniz开发者_如何转开发ation and the Access Control Service to handle authentication.

I have not used any of this technologies before so any advice would be great but I'm searching foremost for errors or shortcomings in this strategy I don't see yet. Is this approach viable at all?

Windows Azure is basically a virtualized datacentre. It is elaborate and complicated and is pitched at corporations who don't want to own their server infrastructure or hardware.

If I understand correctly, what you want is a cloud fileserver, not a whole LAN. Windows SkyDrive fulfils this requirement nicely and offers 25GB of storage per member with no charge for membership.

About Hotmail and Windows Live People often confuse Hotmail and Windows Live, because when you set up a Hotmail account it uses Windows Live for authentication and therefore you end up with a Windows Live account and all the associated facilities, including SkyDrive. However, it is entirely possible to set up a Windows Live account using any email address as the username.

If you do this, it is important to be aware that the Windows Live password associated with a given email address is completely independent of the password required by the mail server that hosts mail for the account. This can cause a great deal of user confusion. For Hotmail (or any other mail server that uses Windows Live for authentication) they are guaranteed to be the same password.

There is no official Microsoft framework support for SkyDrive. There is an open source project called SkyDriveApiClient, but it only works with the full .NET framework. I tried porting it but the author was a bit of an architecture astronaut, and it is absolutely riddled with [Serializable] which is not available on WP7x.

The WP7 guys have said that the WP7 framework will probably include support for SkyDrive but not in Mango (WP7.1) and given that Microsoft's typical release cycle is 18 months and Mango has yet to hit the streets, I'd say it will be two years before you can count on intrinsic cloud file services for WP7.

Roll-your-own wouldn't be hard, WCF services are dead easy to use from WP7. But that's not really cloud since you have to provide and maintain the server infrastructure yourself. For this reason and given the MS timetable, I have put a great deal of effort into producing my own SkyDrive client for WP7. Core functionality is complete and I am now refactoring, improving robustness and adding performance enhancements like local cacheing of tokens (cookies, essentially). I don't intend to release it; I have a number of apps planned that depend on this functionality and it suits me fine that there is a substantial barrier to competition.

I didn't tell you that to tease you. My point is that I'm so sure SkyDrive is the right answer that I put a lot of work into making it happen.

• Cloud file storage is a perfect fit for mobile devices.
• Azure is not a good answer for the sort of phone apps individuals want because the data store isn't shared in a way that required indexing or supports high levels of concurrency
• I can certainly think of corporate phone apps that would benefit from using SQL Server as storage
• Azure can do file services but it represents an ongoing expense. Nobody's going to put up with that when Google and Microsoft both give away web based cloud storage.
• I can personally attest that if you're determined, it is possible to use SkyDrive from WP7.
• Cloud storage is the only way you're going to get programmatically accessible storage that's shared by your user's mobile device and his computer. One of the things I intend to do that depends on shared storage is write a Silverlight app that lets you prepare map routes with multiple waypoints on a desktop computer and a companion app that uses them on WP7.

The Windows Live team has released what they call support for WP7. They supply a sample project showing you how to instantiate a browser object and load their login pages and manipulate them to log in and use their javascript API to manipulate SkyDrive.

This has one big advantage: browser cookies and cached credentials. The disadvantages are obvious; technical shortcomings notwithstanding the Windows Live team seems to think the only thing people want to do with a phone is tag their photos and fiddle with social media.

I have finished my own libraries. They do not support most of the social media twaddle. I have treated SkyDrive as no more or less than a cloud file system, providing

• Authenticate(username, password)
• CreateFolder(folderpath[, blocking=false])
• Delete(fileOrFolderPath[, blocking=false])
• SaveString(filepath, value[, blocking=false])
• LoadString(filepath)

I could handle binaries but Convert.ToBase64 makes this unnecessary and strings are convenient for XML. CreateFolder, Delete and SaveString are optionally blocking. LoadString is always blocking because it's a function that returns the loaded string. CreateFolder is recursive so you can create an entire path in one call (eg /folder1/folder2/folder3). Calling CreateFolder on a pre-existing path has no effect, and SaveString uses CreateFolder to ensure the path is valid, making it unnecessary to create a filepath in advance. Authenticate loads the file system (except file content) into memory eliminating server chatter. This is asynchronous and a FileSystemReady event announces when the file system is completely loaded. The model is maintained as you add and remove files and folders.

This was a lot of work and no one reponded to my attempt to make it an open source project so I'm not inclined to give the fruits of my labour away, but provided your plans don't compete with mine I could be persuaded to come to an arrangement.