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.