Peter McGrattan’s Weblog

Silverlight, WCF, ASP.NET, AJAX, Graphics, RIA

Silverlight 2 Beta 2

Posted by petermcg on June 10, 2008

After a Beta 1 public release that lasted approx three months, Silverlight 2 has now moved on to Beta 2.  This is the first release of Silverlight 2 that has a commercial go-live license, removing another potential obstacle in the decision to adopt the technology for new development.

Plenty of blogs have an overview of the changes here, here, here and here for a start!  Some highlights that I will pick out are that we can ultimately expect over 100 controls for Silverlight, all of which will have built-in support for Control Templates and Visual State Manager customisation.

The Visual State Manager (VSM) is a way to visually manipulate the ‘Parts Model’ of a control and is supported by Expression Blend 2.5 June 2008 Preview.  This is the different visual states and the transition between those states a control allows a designer to modify or completely customize with the guarantee that the logic of the control will not be adversely affected.  The VSM is a feature new to Silverlight 2 that is not currently in WPF; in order to maintain upwards compatibility between the two, WPF will be getting the VSM later this year more than likely with .NET 3.5 SP1.

An ongoing area of particular interest to me (and this blog) will be the the Networking Improvements, the support for Duplex Communication (Server Push) has made it into Beta 2 with the System.ServiceModel.PollingDuplex.dll assembly amongst others.  Two copies of this assembly come with the Beta 2 SDK, one copy under the %ProgramFiles%\Microsoft SDKs\Silverlight\v2.0\Libraries\Client folder and another under the uncharacteristically named ‘Evaluation’ folder at %ProgramFiles%\Microsoft SDKs\Silverlight\v2.0\Libraries\Server, so maybe this support only just made it in…


3 Responses to “Silverlight 2 Beta 2”

  1. Its a shame that the ‘server push’ functionality is actually implemented via a polling mechanism in the Silverlight client (System.ServiceModel.PollingDuplex.dll) rather than a true Comet-style push. How often does it poll I wonder?

  2. Peter McGrattan said

    Hi James,

    Thanks for your comment and apologies for the delay in getting back to you. I will get back to all comments eventually though.

    I have a post in draft form which will elaborate on this subject in more detail but for now : yes the server push functionality released for evaluation in Silverlight 2 Beta 2 (client and server System.ServiceModel.PollingDuplex.dll assemblies) is implemented using a smart polling mechanism.

    This is indeed different to the traditional implementation of server to browser push communication covered by the term ‘Comet’ where most commonly a persistent HTTP connection is kept open between the browser and server using native browser technologies (non-plugin).

    To answer your question, the polling frequency is configurable by setting the PollTimeout and InactivityTimout properties on the PollingDuplexBindingElement class. An instance of this class is instantiated on the client (encapsulated by the PollingDuplexHttpBinding class) and directly on the server. It will be common to set custom values rather than relying on the hardcoded defaults of 1 minute for PollTimeout and 10 minutes for Inactivity timeout. There are walkthroughs that demonstrate creating these classes and setting these properties for creating a client and server in the Msdn library.

    For more on the specifics of what these properties control and how the ‘smart’ part of the smart-polling works, I recommend reading this post by Dan Whalin, especially the quote from Scott Guthrie towards the end.



  3. joshperry said

    Scott Guthrie’s quote from that referenced article (good article BTW):

    “The duplex support does use polling in the background to implement notifications – although the way it does it is different than manual polling. It initiates a network request, and then the request is effectively “put to sleep” waiting for the server to respond (it doesn’t come back immediately). The server then keeps the connection open but not active until it has something to send back (or the connection times out after 90 seconds – at which point the duplex client will connect again and wait). This way you are avoiding hitting the server repeatedly – but still get an immediate response when there is data to send.”

    This (Long polling) is exactly how Comet et al. is typically implemented, MS calls it “Smart” polling, but really it isn’t any more smart than everyone else’s Long polling.

Sorry, the comment form is closed at this time.

%d bloggers like this: