Why the Silverlight UI?

The Silverlight UI that has been employed on sipsorcery.com and which replaces the AJAX UI on mysipswitch.com has caused some serious gnashing of teeth. The two reasons I have been able to distill for the frustration seem to be no Silverlight plugin for browser xyz or OS xyz, which is a fair point, or secondly a dislike of anything Microsoft and the hassle of downloading another plugin. Both those arguments and lots more about the pros and cons of different browser technologies are prolfigate all over the web so I won’t bore you with my own.

The purpose of this short post is instead to explain why the AJAX interface was replaced by Silverlight. There are two reasons:

  • I really really dislike javascript/DHTML programming. It’s incredibly frustrating to switch from a sophisticated IDE and compiled code language such as C# (or Java if you’re that way inclined) back to fiddly little HTML tags and a hodge podge of javascript libraries and browser hacks which is otherwise know as AJAX (Asynchronous Javascript and XML). Some programmers thrive on AJAX, I’m not one of them.
  • Silverlight has this massive thing under the hood called the Common Language Runtime (CLR). The CLR is what runs the latest version of software developed on Microsoft’s .Net platform. The Silverlight CLR that runs in a browser is a cut down version of that runs on a desktop but it’s still suprisingly comparable. In contrast to AJAX development I find C# development to be the bee’s knees and makes programming fun rather than like putting hot pokers in my eyeballs. Because of the CLR a Silverlight application can also share code with non-Silverlight applications. In the case of sipsorcery the really big thing is that the SIP stack which drives all the servers can actually run in the browser. What that means is some very cool SIP applications can be developed.
  • In answer to a question about whether the sipsorcery UI could be targetted to the Silverlight 1.0 runtime so that it would run with Moonlight (the Linux port of Silverlight) the answer is unfortunately no. Version 2 of Silverlight is the first one that included the CLR and that’s the whole point of sipsorcery using Silverlight.

    1. anon’s avatar

      Have you considered the Google Web Toolkit? Supposedly you can program in Java and have the toolkit spit out JavaScript. I’m sure Silverlight will never run on my mobile phone browser, and needing a full computer to adjust my dial plan is a non-starter for me.

      http://code.google.com/webtoolkit/

      Reply

      1. sipsorcery’s avatar

        I do understand where you’re coming from. The issue isn’t so much about the technology it’s more that my interest and drive at the moment is to explore rich SIP client apps and Silverlight is my preferred vehicle. What’s needed for a mobile phone browser UI is a programmer with the drive to write it :/. Maybe one day that will be me. The opportunity is there for another programmer to come along as all the communications between the sipsorcery client and server are done through a web service interface (https://www.sipsorcery.com/provisioning.svc) that can be consumed with javascript. I’m also planning on implementing a REST interface for the same methods very soon to make it even easier to integrate with.

        Reply

      2. Tuketu’s avatar

        I can totally understand where you are coming from. I love the “hot pokers” comment, it brought back memories I’ve been trying to supress 🙂 Silverlight is some neat technology and certainly a joy compared to DHTML and javascript.

        As to silverlight on mobiles: at some point in the future Silverlight will run on some mobile phones. Until that time, the feature request could be handled with a simple/stripped down UI at sipsorcery.com/mobile, but I know that’s more work and frankly, for most users, would probably be pretty low on the feature request.

        Keep up the good work…we all appreciate it.

        Reply

    Reply

    Your email address will not be published. Required fields are marked *