Question about Architecture for Viewing Images in ASP.NET MVC App

I have an approach in mind for an image viewer in a web app, and want to get a sanity check and any thoughts you stackoverflowers might have.

Here's the whirlwind nutshell summary: I'm working on an ASP.NET MVC application that will run in my company's retail stores. Even though it is a web application, we own the store machines and have control over them. We have a "windows agent" running on the store machine which we can talk to from the browser via javascript (it is a WCF service, and our web app has permission to talk to it from the browser).

One of the web pages needs to be an "image viewer" page with some common things like Rotate & Zoom.

Now, there are some WebForms controls that offer Rotate and Zoom. However, they take up server resources and generate a good bit of traffic between the server and the browser. For example, the Rotate function would cause an ajax call to the server, which would then generate a new image written to a .NET Canvas object, which would then be written to a file on the server, which would then be returned from the ajax call and refreshed inside the browser.

Normally, that's a pretty good way of doing things. But in our case, we have code running on the store machine that we can communicate with. This leads me to consider the following approach:

1. When the user asks to view an image, we tell our "windows agent" to download it from our image server to the store machine.
2. We then redirect our browser to our image viewer page, which will pull the image from the local file we just wrote to the store machine.
3. When the user clicks "Rotate", we cause JavaScript code in the browser to call our "windows agent" software, asking it to perform the "Rotate" function.
4. The "windows agent" does the rotation using the same kind of imaging control that would formerly have been 开发者_运维百科used on the server, but it does so now on the store machine.
5. Javascript in the browser then refreshes the image on the page to show the newly rotated image.

Zoom and similar features would be implemented the same way.

This seems to be much more efficient, scalable, and responsive for the end-users. However, I've never heard of anything like it being done, mostly because it's rare to have this combination of a web app plus a "windows agent" on the client machine.

What do you think? Feasible? Reasonable? Any pitfalls I overlooked or improvements / suggestions you can see? Has anyone done anything like this who would like to offer the wisdom of experience?

Thanks!

I've never done anything like this before, but the first thing that comes to mind is why not use Silverlight for the image viewer, or possibly flash?

Upon further thought, we did something MUCH simpler (always good when you can find that). I didn't realize at the time of this writing how simple it is to rotate and zoom images using JavaScript. In fact, we have to support IE (and only IE, since the product is used in our stores and it handles integrated authentication slightly better) ... so the rotate was done with IE filters and the zoom was done with CSS. Lets us be stingy with round-trips and deliver the features efficiently.