« Visio Automation: Three Hello World Samples – C#, F#, and IronPython | Main | Speeding up Visio automation by batching via SetFormulas(), GetFormulas() and VisDOM »

Notes on Using Client Applications to Generate Server-Side Graphics

Occasionally I am contacted by someone who wants to generate some graphics content on a web server and they want to use a client application like Visio or PowerPoint or Photoshop as as an engine to generate those images dynamically on a web server. They are often looking for some guidance on whether this is a better approach than, for example, manually creating the images using custom code.

The fundamental issue is that client applications are (usually) never designed to be run in this scenario.

Typical issues one will encounter

  • Simultaneous requests – A single instance of a client applications will often be unable to handle multiple client requests at the same time. You may have to spawn multiple instances or queue the requests. (I’ll leave identifying any threading issues as an exercise to the reader)
  • Security – You’ve got to be careful to examine the potential risk of running a client application in a server context. For example, can a client use malformed input to cause the application to do something that would put the server at risk? You need to think about the threat model for this scenario.
  • Interactivity – Client apps tend to assume that there is a human sitting in front of a monitor using the app and so will show UI (modal dialogs, etc.). When there is an interactive user, this is no problem, the user handles or dismisses the UI and continues. On the server side, you may find that the client app will try to launch some interactive UI and will either outright fail or simply block waiting on user input. A typical example are the “File already exists. Do you want to overwrite?” dialogs. You’ll have to code around these issues if you can.
  • Licensing – The license under which one uses the software may explicitly or implicitly restrict or forbid its use as a server-side application.
  • API support – Some client apps allow a user to interactively create content but does not provide an API to do so programmatically. Sometimes if the API is exposed, you may find that the API is quite limited compared to what an interactive user can create.
  • Performance and Memory Usage – you may find that even low numbers of requests per unit time that the client application consumes too much memory or CPU cycles.

My Recommendations

  • (a) Roll-your own.  XML-based vector formats like SVG or Silverlight might be good candidates here because it is simple to create the content.
  • (b) Re-use an existing library that is built for generating server side graphics (example: libgd)

Even with this recommendation one will have to consider most the issues I’ve identified earlier, but at least one will have more control over those issues.

Update [2008-08-09]: Additional links

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>