Monthly Archives: December 2009

A follow-up for the <input type="file"> issue

So it appears that Firefox has had a bug submitted for “Improved form upload manager/progress display“… since 2004. So, if you use Firefox, please log into bugzilla and vote for this bug.

Alternatively, if you are an IE fan, please log into Connect and vote up the bug that I just submitted.

Advertisements
Tagged , , , , ,

Dear Browser Makers: Please fix <input type=”file” />

tldr: Browsers need better ways of handling large HTTP requests – possibly with an "upload monitor" (Scroll to the last paragraph for a little more)

I think that we’ve all come across this before: you go to a website, select a file to upload, hit “Submit” and then wait forever and hope that the file you’ve selected has actually made it to the server on the other side. Recently, while building an ASP.NET MVC application for a client, I decided that I wanted a better experience for my end users, especially since this application is to be externally hosted from the client, who is the primary user. As such, I didn’t want the client to be waiting and hoping that the documents and images that they are uploading are actually reaching the other side.

So, to get past this issue, my first idea was to turn to AJAX. Using JavaScript made sense as it meant that no 3rd-party plugins are required and that anyone with JavaScript disabled can still upload files (albeit with a worse interface – but anyone disabling JavaScript should expect that). Unfortunately, AJAX file uploaders appeared to be mediocre at best – they were inaccurate with percentage (if they showed a percentage), the interfaces were pretty poor and most didn’t support multiple file upload features (such as selecting multiple files in the open file dialog).

With a quick bit of searching, I found SWFUpload – which appeared to have all the features that I wanted: a nice interface, multiple file uploads and very customisable. Having implemented SWFUpload into my application, I hit a major bug. As it turns out, SWFUpload was built using Flash, and Flash (being the wonderful Adobe application it is) only sends cookies from Internet Explorer, if at all. This meant that the uploading component would not use the same session as Firefox, and so would be redirected to the "log in" page instead of uploading the file. The suggested fix from SWFUpload didn’t work (apart from the various security exploits it introduced) and implementing my own SessionIDManager (to permit session id’s in the query string) failed due to ASP.NET’s SQL Membership Provider storing additional Authentication data in a separate cookie.

Luckily enough, Silverlight supports sending the cookies from the browser it is hosted in. Hoping for a simple, drop-in solution I was (again) severely disappointed. The Silverlight component I had chosen (Silverlight Multi File Uploader), as well as many others, send the file in the body of the HTTP request (instead of putting it in a mulitpart/form-data encoded POST header) and chunked the upload. This was greatly frustrating as I wanted to put the uploaded file straight into the database, without placing it temporarily on the file system. After some hacking of the Silverlight component, I was able to strip out the chunking code, but attempting to have the request use mulitpart/form-data failed due to Silverlight’s unusual (but rather logical) way of doing HTTP Requests. Silverlight relies on the browser sending the request and completing its headers (such as Content-Length). However, the Content-Length header is put before the Content-Type and this causes IIS (and, most likely, every other webserver) to ignore the POST variables. In short, I couldn’t have the file uploaded properly (ie appearing in the Request.Files array), but I could live with put it in the HTTP Request body (and access it via the Request.InputStream stream).

But enough of the backstory – what is to be done? Well, its quite simple. The user’s browser should realise that it is uploading a large file and show the user how much of the file is complete (and, possibly, speed and estimated time). I find it curious that the user is presented so much information about a download and yet next to nothing about the statistics of an upload. When you think about it from a web developer’s point of view, the browser is the only place to implement this feature. Why? Because HTML is for content, CSS for styling and JavaScript for functionality. Out of those three, JavaScript is the best candidate for implementing an upload "monitor"; but JavaScript has no information about the OS the browser is in (nor should it), and so there is no way for the JavaScript to know how large the file is – this means that the responsibility falls out of the Web Developer’s hands and into the browsers hands.

Tagged , , , ,

SharePoint: I… Understand

A common question I get is "what is SharePoint?" – especially when installing a fresh copy of Windows Small Business Server (which comes with SharePoint inbuilt). My honest answer has always been "I have no idea, but I don’t think you’ll need it"

But now I understand what SharePoint is thanks to the following short video – and how wrong I was about people not needing it.

http://www.microsoft.com/video/en/us/details/76e8d3af-c2bd-42a6-bb12-befcbd041bf1

Tagged , ,

Office Development in .NET is a Mess

First off, a bit of a disclaimer – I admit that I am using Visual Studio 2010 (Beta 2) and Office 2010 (Beta); as such I shouldn’t expect all documentation for them to be complete or everything to being running bug free.

With that said: Begin the rant!

Today I decided to attempt to build an Outlook 2010 add in that would enable me to "block" particular authors on RSS Feeds. The reason I wanted to do this is that I am subscribed to the TechNet, ASP.NET, MSDN and Windows Team combined feeds – these 4 "combined" feeds are a collation of quite a number of blogs by Microsoft. The unfortunate thing is than a number of the blogs are completely irrelevant to me, or in a foreign language. With my Add In I could then block the non-English and irrelevant authors without having to create a-hundred-and-one "rules". So, what went wrong?

First off, there is no "RSS" class.
RSS items are of type PostItem or, more specifically, have a MessageClass or IPM.Post.RSS. So while it is possible to tell that an individual Post item is an RSS item (by doing a string comparison), its impossible to filter or check folders. This isn’t a *big* thing, but it certainly is very annoying.

Don’t use the classes, use the interfaces.
For every VBA class, there is a .NET Interface AND a class; for instance there is an Outlook.PostItem (Interface) and Outlook.PostItemClass (Class). So which to use? Apparently the interface is the one to use, I think. The classes are apparently "COM coclasses that are required for interoperability with the corresponding COM object" – which to me sounds like an Infrastructure class, which is fine if it is private or internal, NOT public. Also, in case you didn’t notice, to add insult to injury there is a class with the word "Class" in its name that is referring to the fact it is a class (and the interface isn’t prefixed with an "I" – but we’ll forgive that).

The documentation is incomplete.
And its not just the 2010 documentation that is incomplete. To use the example above, lets have a look at the PostItem Interface members (Go, click on the link and have a look. I’ll wait right here. Done?). That’s right – they’re empty. But IntelliSense in Visual Studio (and the actual API) tell a different story. Ok, lets assume that (being programmers) they’re lazy. maybe the documentation is in the PostItemClass Class (Again, click on the link…). Hmm…. apparently all of the Properties, Methods and Events do the same thing… which is the same thing as the Class…
Oh, and in the name of fairness, reopen one of those links and check the version of Office the documentation is for. That’s right, 2007.

And, the Pièce de résistance:
Apparently Outlook is now Access in Office 2010 (click on the "Outlook 2010" link) (also, Bing’s cached version, just in case)

Tagged , , , , , ,

Multithreading Analogy

I’ve always been a bit contentious about starting my own blog, “Is it worth it?”, “Will I blog enough?”, “Will people event read it?”, etc. However, after reading this post from the MSDN, I realised that I may as well – even if it is just to repost nuggets of information like this:

This is one of *the* best analogies for how multithreading works and where the performance and stability of issues that poorly written multithreaded applications derive from. Its a bit of a long post, but well worth the read: http://blogs.msdn.com/dsvc/archive/2009/12/10/the-cup-stacker-prince-multi-threading-made-easy.aspx

Tagged , ,