views:

47

answers:

1

I'm faced with setting up a system which will allow users to:

  1. Hit a button to initialize a "download & archive" command, which reads file lists via XML, pulls files over HTTP to a local directory, archives them, and stores them away for download.
  2. Get a progress bar/indicator telling them their "request is being processed" immediately after pressing aforementioned button.
  3. Be able to submit another "download & archive" command without waiting for previous request(s) to complete.
  4. As each "download & archive" command completes, a pool of completed archives should grow by one with the new archive available for download.

How should I go about keeping track of the ongoing process which occurs during step 1, and how should the proper events/messages be communicated back to the UI as required for step 2 and 4?

How does the UI know about the ongoing processes? Magic folders and tokens on the file-system? Session state? A database which is written to by the process, and read from by the front-end code?

I was wondering if this is something that is encountered frequently and has a "standard way" of being implemented?

FYI, my stack is:

  • ASP.NET MVC 2 on .NET 4
  • IIS 7
  • An external 7zip library for .NET
+1  A: 

On the Client which in your case is the MVC Controller create an explicit Command object which has an Identity (most likely a GUID). Then send a one-way message by spawning a new thread or via a ServiceBus to your backend process and return the Commands Id back to your View.

While your backend process is working your View can poll (using JavaScript) for the existence of a URI. e.g. http://www.mysite.com/asyncresults/GUID.js

Then your backend process can create the GUID.js on the file system with JSON objects that give you enough information to render progress updates.

As the client is polling for the File it will receive a 404 until such time as the file exists. When you receive a 200 you can use the JSON contained to render your UI.

This solution is scalable and simple to implement.

willbt