Alex Hopmann’s Blog

Uploading any files more than a few hundred K from a browser has been a problem for years. The UI available in the browser is very limited and relying on a single HTTP request that might take minutes or hours (and that you have to start over from scratch if it fails) often turns into a huge source of user frustration. There is also an extra flaw in that the TCP connection can fail before the whole file is transmitted but depending on the circumstances the server might not be able to tell if the whole file was actually received. There are a bunch of sites that use various ActiveX or Java controls but those have typically been a pain to install and/or flakey.

I just discovered that Silverlight can be used to create much more functional upload controls. Here is one for example in the Codeplex Code library. Granted, users need to have Silverlight already installed, but once they do it becomes much easier to have a good user interface, while having the actual process send chunks of the file that can be resumed if any piece fails, etc. Combine that with the Azure Blob chunked-PUT mechanism and you can build a very robust storage mechanism right in the browser. I’m looking forward to trying it out.

One last thought- it would be useful to define a standard protocol for uploading content in chunks (and yes, this is distinct from an HTTP PUT/POST with chunked encoding). Something along the lines of what the Azure Blob store does but defined as a standard that various controls and services can all interoperate.

Fil posts about a cool library he made called Sistr that lets you use Silverlight to render high quality fonts. This is a good example of the power of Silverlight (since it really enables you to use markup for stuff in your normal HTML page way). But its also unfortunately the kind of thing that isn’t going to be adopted much until Silverlight gets deployed more widely. I suspect no one wants to force people to do a download just for somewhat better visuals.

Which brings up an interesting feature suggestion (which might already be there). If Sistr made it really easy to fall back to the standard HTML rendering (or a PNG file) when Silverlight is not installed rather than pushing the Silverlight install, this could be easier to adopt. Since it supports the same HTML markup already, that should be fairly straightforward, although the rendering can be so different that designers might not like that approach.

Or another approach would be a web-service that creates the PNG server-side for users that don’t have Silverlight. Cache it so you don’t re-render on every request, but make the developer story just as easy as putting markup in a page (as easy as the existing Sistr).