The past week or so has been getting a Silverlight client to successfully call my web service for serving up textures. What I thought was going to take under an hour took an eternity. Here's why:

1. Silverlight apps can't make cross domain web service calls. For security purposes an app hosted on www.foo.com can't call a web service on www.bar.com. It makes total sense. Problems start to pop up though when you're developing on your local box because it treats localhost:80 as a different domain than localhost:81. Since you can't have your local web service and web server on the same port you are screwed. There are a number of work arounds for this, one of which I got working, but they are all poorly documented since Silverlight is still in beta. Needless to say I lost countless hours getting this working.

2. After I get a nice binary blob coming into my Silverlight app my next step is to use that to construct an Image object. Unfortunately unlike the Image class in my winforms app there's no way to create an Image object from a memory stream in Silverlight. Once again for security purposes I'm sure.

3. I do find a way to dynamically create an Image object using a Downloader object. The downloader is a glorified wrapper around a URL. You pass it a URL and it downloads the image in the background and fires off an event when it's done. A glimmer of hope shines in my eye as I figure I just need to implement my own version of the Downloader object that sucks the data in from my service instead of a URL. Once again I'm busted as Silverlight won't let you derive a class from the Downloader object.

All in all my troubles show that getting some rogue data into a Silverlight app isn't easy. I have to assume that Flash does similar things. While this is great to keep the sandbox in your browser safe it does limit what developers can do. Now instead of having my service serve up data blobs it has to serve up URLs. Which means keeping data on the web server file system which is a whole lot less elegant than just having it in a DB. In the long run it may end up being a better solution performance wise but it just isn't as much fun.

I currently have the new service up and will be testing it from a Silverlight app in the next couple of days. Wish me luck.