ISerializable - Roy Osherove's Blog

Just like you say the browser was never meant to be a 'real' application platform, let me add this: .NET WinForms were never meant to be a real 'universal' solution.

At least a browser guarantees you some standard kind of exporsure on Linux and Mac. At least a browser guarantess you exposure on that Win98 box with only a 56k connection to the web.

I guess what I'm trying to say is that each arena has it's pros and cons. Yes, you have no easy nor simple way to make an intelligent progress bar in a browser app. On the other hand, this forces you to develop disciplines you might not otherwise hone. Do you really want create web apps that force a 20 meg download just ot run them? One that really needs that intelligent progress bar? Because if you do then you probably have WAY too much happening... a download that would be a complete dog over a dirty phone connection.

Personally I think the greatest way to challenge a WinForm developer to hone their skills is to ask them to develop in .NET CF. If you can get your app to work with the limitations of that subset, you've probably made something that will not only scale well, but also has a simple interface and blazing performance to boot!

Now, in answer to your original problem, I've used two solutions in my ASP apps. (This is already assuming you rethought why you must force the user to wait long enough to need that progress bar - and have no other recourse.) First off, make a 'dumb' progress bar. Some simple DHTML will do the trick. Second off, provide 'intelligent' feedback.... "Step x of x...." or give them numbers and figures, but stream it line by line to the browser. The user doesn't have to understand it, they just have to know things haven't grounded to a standstill.

I had a finance system load. Intranet app. Lots of number crunching. Couldn't tell the user no. In that case I opted to have the web server make one call to get back the calculated data and then make several sequential calls to update the database one account at a time. That way I was able to tell the user - account by account - exactly what I was writing to the database. When finance 'pulled' the data in several departments at a time (a process that took about 10 minutes) they were left not only with frequent feedback - but relevant feedback also. Yes, it was a hack. Yes, I could have asked WHY THE HELL IT IS SO MUCH MORE DIFFICULT. Instead I took it as a challenge to be creative - and unexpectedly developed a much appreciated 'feature' of my app. (Not only from a finance standpoint, but a debugging one too!)

Dave: Thanks for the relevant feedback. I agree with most of what you said. Perhaps I should have re-labled this post: "Rant:".
Yes, I love these kinds of challenges. But consider a different view:
If everyone who has ever encountered a problem would just say "Great , a challenge" and tried to find a workaround, and noone ever bothered to say "why is it so hard? let's make things better/easier/faster" we wouldn't get where we are now. We would still have ASP, not ASP.Net. Actually, we still might be in the COBOL days.

Still I see what you mean. Thanks.

I've had to integrate something quite recently that could potentially take a long time to run, and I wanted to give the user feedback, the solution I opted for was to utilies MSMQ and a Windows Service to listen for events on the queue. The ASPX page after submitting checks every 3 seconds to see if the job is complete. This solution works if you have full server access.

HTTP is a pull only mechanism, that's something you have to deal with when you code for it. You can get your client to query you several time but you can only answer to a client request, not push anything back to the client. This is a limitation of the protocol that was never meant for anything else than pulling data from a server. Honestly there is no point in complaining that it sucks, especially more than 10 years after is was first invented, thats just the way the protocol was meant to work and what we have to deal with. Any protocol has it's limitations and drawbacks and are meant to solve a specific set of tasks that evolves, slowly becoming more and more difficult to adapt... That's the way things goes in computer science, and honestly more than 10 years and still a long life ahead of it is a VERY impressive achievment for HTTP.

Microsoft just recently came out with an Asynchronous Application Block, which could provide some good info on this: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/PAIBlock.asp

I like to use Remote Scripting in these situations which allows you to call back (poll) to the server to track progress without refreshing the page. Then I simply update a DHTML progress bar with the results.
I have done this in ASP
http://msdn.microsoft.com/scripting/remotescripting/default.htm
and continue to do it in ASP.NET
http://www.thycotic.com/dotnet_remotescripting.html

Another alternative which would be a little tedious would be to write an applet that connects back to the server and listens for "push" updates regarding the status. This obviously would have scalability implications though due to the persistent connection.