I attended the .NET SIG at the Microsoft offices in Independence last night. John Stockton presented Silverlight to the group. He did a very nice job. It was sort of an intro-level discussion of Silverlight with a focus on how Silverlight can consume and connect to various sources of data. Below are my notes from the session

  • Backwards Compatibility
    • Silverlight plugins are backwards compatible. Version 2 will run apps written against Silverlight version 1.1.
  • Cross Domain
    • Silverlight can do cross-domain connections to web services, but it must be explicitly enabled by the remote service. This is done by placing an XML file on the root of the server that hosts the web services. This file specifies what clients can connect to that service.
  • SOAP Support
    • Can do SOAP calls to remote web services.
    • Only supports SOAP 1.1 (not 1.2)
    • Only supports the WCF Basic Http binding. It cannot do any WS-* protocols
    • All calls are done async. This is because Silverlight uses the networking stack of the browser. The browsers only support async.
  • Available Proxies
    • Can get data using a variety of other “Plain Old Xml” type endpoints (REST, RSS, ATOM, POX/XML, JSON).
    • Proxy options include:
      • Service Reference (for SOAP web services)
      • HttpWebRequest (for lower level control of the request)
      • WebClient (for an easier way to access REST / POX services)
    • HttpWebRequest only supports GET and POST verbs. No support for PUT or DELETE verbs yet.
  • Connection Limits
    • Most browsers follow the standard’s recommendation of only opening 2 simultaneous connections per sub domain. This constraint is valid for Silverlight too since it uses the browser’s networking stack. You cannot make more than 2 web service calls to a remote server. Additional connections might just queue up and wait for the existing 2 connections to complete.
  • REST / POX / XML
    • No REST specific API. Just use the WebClient or HttpWebRequest to make the call.
  • RSS / ATOM
    • Includes a SyndicationFeed API for consuming RSS type feeds. This abstracts the details of whether the feed is RSS or ATOM. It provides a nice wrapper around the data.
  • JSON
    • Includes two options for dealing with JSON services:
      • JSON object, which can be consume via a LINQ query against the object.
      • JSON serializer, which will serialize / deserialize to and from .NET classes.
  • XML Handling
    • Support for three ways to read / write XML
      • XmlReader (harder, low level access to XML)
      • LINQ to XML
      • XML Serializer
    • XmlDocument is not in the Silverlight framework. This was a design decision where they chose between LINQ to XML or XmlDocument. In the end they chose LINQ to XML for it’s richer use cases.
  • Quirks
    • If the Silverlight app makes a remote call to a web service, which in turn errors, then the web service response will always get a 404 – File not found error. It sounds like Silverlight cannot consume SOAP Faults or WCF’s FaultExceptions. These will always show up as a 404. This is also the case for many other types of failures on the remote server. They almost always show up as 404s.
      • This may change in the future, but for now the recommended work around is to return the error information as part of the method call. This could be a return value, or it could be an output parameter.
  • Data Binding
    • Data is bound to a control or page by setting the control’s DataContext equal to the data that should be bound. Then the control uses binding expressions to bind properties to the values in the DataContext.
    • Binding Expressions look something like “{Binding FirstName}”.
  • Isolated Storage
    • Silverlight can store some data locally. By default this is about 1MB, but the app can request more from the user.
    • Data is stored in the browser’s temporary Internet files directory. This means that the data goes away if the user clears their temporary files.
  • Resources
http://twitter.com/johnnystock