Silverlight 1.1 turned out to be such an important upgrade for Microsoft that it was eventually renumbered Silverlight 2. As delivered now, Silverlight 2 supports all .Net languages, including the dynamic languages such as IronPython and IronRuby, and it contains a good chunk of the .Net base classes, including newer features such as LINQ (language-integrated query). In addition to a rich set of controls with more on the way, it has APIs for an alphabet soup of networking, including REST, SOAP, RSS, and HTTP; includes local data caching and storage; and supports HD video among other rich media formats. H.264 video and AAC (Advanced Audio Coding) audio support is planned for Silverlight 3.
Poster-child Silverlight deployments such as the Beijing Olympics last August have been favorably reviewed and generally well received. There was of course the usual chorus from people with incompatible hardware and operating systems, but nothing unexpected. From Microsoft's viewpoint, at least, the Silverlight Internet video streaming of the Olympics provided by NBC in the U.S. China Central Television in China, and broadcasters in 10 other major national markets, was a huge success. More recently, Silverlight 2 enabled Blockbuster to offer high-quality streaming video to PC and Mac users of its MovieLink service.
Capabilities and controls
Silverlight 2 should eventually be good for any kind of RIA, given its strong language support and class library and good runtime performance, not just video streaming. Right now, it probably lacks a few user interface controls out of the box for some applications: There are only 28 items in the standard Silverlight Controls toolbox, and another 12 in the Silverlight Toolkit, with a plan for 100 controls total to be made available over the next months. It's not that hard to build new Silverlight controls, and many are already available from ISVs, but if you're not in a hurry, you may find that Microsoft eventually delivers all the controls you need.
Security in the face of cross-domain access is a potential issue for any browser-based application, whether or not it uses a plug-in such as Silverlight or Flash. Silverlight does have its own cross-domain security mechanism, controlled by a manifest file setting, which defaults to the most secure setting.
I have seen accusations online that the Silverlight local data storage might still be vulnerable to cross-domain attacks despite this mechanism, but I haven't been able to prove or disprove this. The same source claims that Flash local objects are open to the same kind of attack.
Development and design
The basic method for programming XAML elements is to give them a x:Name tag, for example:
<TextBlock x:Name="message1" Text="Message:"> </TextBlock>
message1.Text = "Hello, " + name1.Text;
This connection between program and XAML element by name is the key to using teams of programmers and designers to develop Silverlight and WPF applications. As long as the names don't change, the programmers can modify the code-behind files, and the designers can modify the XAML files without breaking the interface between the two. They might not even use the same tools.