２、OpenID-网络用户集中认证
　　相信每个网民都有不下一个的网络ID，新浪的，网易的，yahoo的，Hotmail的，如果要享受某个网站的服务，我就得先注册成它的会员，并且不同网站的用户之间的通信也存在障碍。
　　如果能有一个通用的帐号，能在各个网站畅通无阻，这将大大提高用户的上网体验，也没必要记那么多的帐号与密码了。
　　这事最闹心了，本来我在各大网站的用户名都是snowwolf的，可在某些网站，也不知谁先给抢注了，我就只得改用snowwolflibo，结果是上网时，我也不知道哪些用户是snowwolf，哪些用户是snowwolflibo。
　　现在好了，有了OpenID(据说是微软,Google,Yahoo等力挺的一个概念，具体是什么，我也说不清，反正很拽)，各网站可以把用户认证管理托付给另一专注于OpenID服务的系统，实现整个互联网的单点登录。
　　除了网站，IM工具的互通互联也势在必行，看看现在的白领一族，每天打开电脑第一件事就是启动各大IM工具，QQ/MSN/Fetion，据说现在又有了百度Hi。我们的桌面早已凌乱不堪了。
　　当然IM与网站的集中认证的推行瓶颈不在技术，而是商业层面的东西。所谓的互联可能会先在市场份额小的产商中进行，如百度Hi就宣称要支持互联。但互联也可能出现在大产商对小产商的并购中。这听起来有点像战国时代的“合众”与“连横”。

            this.slider.Minimum = 0;
            this.slider.Maximum = 100;
            double seconds = this.mediaElement1.NaturalDuration.TimeSpan.TotalSeconds;
            for (int i = (int)this.slider.Minimum; i < (int)this.slider.Maximum; i++)
            {
                TimelineMarker marker = new TimelineMarker();
                double time = seconds / this.slider.Maximum * i;
                marker.Time = new TimeSpan(0, 0, (int)time);
                marker.Text = "a";
                marker.Type = "Test";
                this.mediaElement1.Markers.Add(marker);
            }

　　在此需要注意的是，一定要设置marker.Type，否则您试试，一运行程序就崩溃了。呵呵。
　　好了，接下来在MediaElement.MarkerReached事件中添加以下代码：

            double time= e.Marker.Time.TotalSeconds;
            double seconds= this.mediaElement1.NaturalDuration.TimeSpan.TotalSeconds;
            if (seconds <= 0)
            {
                return;
            }
            double marker = (time * this.slider.Maximum / seconds);
            txtSlider.Text = e.Marker.Time.Hours + ":" + e.Marker.Time.Minutes + ":" + e.Marker.Time.Seconds;
            this.slider.Value = marker;

　　在此，我们根据当前Marker的时间点与总时长算出播放时间占总时间的比例，然后计算出Slider当前应该的进度值。就ＯＫ了，如果要显示当前时长的话，只要txtSlider.Text = e.Marker.Time.Hours + ":" + e.Marker.Time.Minutes + ":" + e.Marker.Time.Seconds;即可。

　　然后我们再实现进度条的拖拽功能。
　　在Slider.ValueChanged事件中添加以下代码：

            double seconds = this.mediaElement1.NaturalDuration.TimeSpan.TotalSeconds;
            double time = seconds / this.slider.Maximum * this.slider.Value;
            mediaElement1.Position = new TimeSpan(0, 0,(int) time);

　　一切搞定！
　　不过细心的你可能会发现一个问题，那就是MediaElement.MarkerReaded可以改变Slider.Value，而Slider.Value的改变又会引发Slider.ValueChanged，该事件中又有MediaElement.Position=v，这又会引发MediaElement.MarkerReaded，呵呵，死循环吧，没关系，自己加一个信号变量就行了。这我不再详述了。
　　

　　Silverlight 2 Beta 1版本缺陷列表

　　1、WebService不支持同步调用
        在SL工程中添加Service Reference后，自动生成代理类ServiceSoapClient，实例化ServiceSoapClient后，我们只能看到异步调用的方法。比如，我的WebService提供了一个GetVideoTypes方法，在ServiceSoapClient中却只有GetVideoTypesAsync与GetVideoTypesCompleted，前者是异步方法，后者是相应的事件。上网找了资料，发现在有的外国论坛上，有人也提出了这个问题。

　　２、WebRequest不支持同步调用
　　　与WebService一样，WebRequest也不支持同步，具体不再详述。在此说一下，WebRequest在System.Net.dll中，大家在开发时要自动引用一下。

　　３、System.Runtime.Serialization.Json.DataContractJsonSerializer方法不友好
　　　在SL2 Beta 1中用JSON，我只想说，这是一个比较奢侈的要求，目前MS封闭的System.Runtime.Serialization.Json.DataContractJsonSerializer类接口函数很不友好，只支持ReadObject与WriteObject，没有我期待的Serialize与Deserialize。呵呵，你看看ReadObject接受的参数是什么，Stream!!哈哈，你还要构造一个Stream，而如果在分布式系统中，这个Stream就要从WebRequest与WebResponse得到了，嘿嘿，这两类还不支持同步调用。麻烦啊。不过我记得早期版本是有Serialize与Deserialize的，不知道是给去掉了，还是我没找到。
　　BTW，System.Runtime.Serialization.Json.DataContractJsonSerializer在System.ServiceModel.Web.dll中，很不好找啊。

　　４、对相对路径支持很不好
　　我有一个视频播放的页面，要动态加载一些图片，一开始这可把我难住了。因为SL是客户端执行的，而这些图片是在服务器上。我在Xaml中直接写相对路径如"images/1.png"，不好使。为什么呢，我觉得也是可以理解嘛，毕竟SL在客户端执行，客户端哪有这个文件，但你SL的Runtime是不是应该动态的去服务器把这图片download下来啊。我记得老版本是可以的啊。没办法，我一开始只能写完整的uri，如http://localhost/vodsl/images/1.png。
　　不过还有一个奇怪的现象，在同一个SL页面中，有的图片显示不出来（如果用相对路径的话），但有的图片又可以显示。My God，想来想去，答案是：SL还是做了动态下载，只不过这个下载可能在SL渲染后完成，就是说有的图片下载不赶趟了。

　　
  　５、重绘SilderBar控件会让你抓狂
　　SL 2 Beta 1引入了TextBox Button ScrollBar等控件，值得夸奖，毕竟在1.1时，自己封装TextBox 还麻烦了（绝对地狱似的编程）。
　　而这些控件在美观上是远远不能满足人们日益增长的审美要求的。于是乎，我想重绘它们。感谢SL为我们提供了重绘控件的机制。具体方法是为控件(如：Button ScrollBar)指定Style，这个Style其实就是一个Resource，你可以直接在Xaml中写。但要写在相应控件的前面，否则在运行时，SL会认为控件的Style是一个无效对象。
　　但定义这一个Style可不简单耶！！看看SDK中的例子，那是相当长的一段代码。而且你很难知道控件的各个元素叫什么名（我是通过SDK／Google才知道的）。很不人性啊。其实我就是想改一个小滑块的样式，（ScrollBar中的小滑块），就要写一大堆Xaml。大家可以试试，我是花了很长时间才明白这大堆Xaml的具体含义。
　　好了，终于可以自定义ScrollBar的样式了，但发现ScrollBar总有一个背景图去不掉，就是下面这个图片:

　　无论我怎么修改Style，这个底图总存在。没办法，我最近只好放弃重绘ScrollBar。

　　６、说说Grid与DataGrid
　　Grid是SL的一个相对定位容器，在Grid中的控件是不能绝对定位的，如果你也与我一样试图在Blend中拖动Grid中的控件，一定感触颇深。我觉得这是很合理的，Grid就像Html中的Table，可用作页面整体的布局，事实上SL的很多控件（比如ScrollBar)内部也是用Grid布局的。但Grid没有提供Rows.Add与Columns.Add等接口，在想动态放置子控件时比较不方便。但Grid引入了RowDefinition与ColumnDefinition的概念，这个我个人比较喜欢。它实现了Grid布局定义与子控件放置的分离，你先定义Grid有几行几列，然后在后面加子控件，再为这些子控件指定Grid.Row与Grid.Column，这样就避免了HTML Table中的层层嵌套。这样的缺陷就是不代码不直观。
　　BTW，Grid的单元格似乎不能自动随子控件撑大，我只看到了Maxheight与MinHeight属性，但似乎不能实现这个功能。
　　DataGrid居然没有Rows.Add接口，但有Columns.Add接口。

　　７、有些属性要通过SetValue与GetValue方法
 　　.Net 3.0与SL引入了DependencyProperty机制，很好很强大，我们可以在一个类中定义属性，然后别的对象也能用这个属性，没有明白？比如说在Canvas中定义了Left，我们可以在任何控件对象中SetValue(Canvas.Left,v)。凡是可以嵌在Canvas中的控件都可以通过这种方式来设置Left；而Grid也有LeftProperty，同样，凡是可以嵌在Grid中的控件都可以SetValue(Grid.Left,v)。仔细想想，不难发现，在任何一个控件对象中SetValue(Grid.Left,v)，最终都会调用Grid类中的一段逻辑。你要是自己定义一个容器控件，比如MyPanel，你在这个类中加一个LeftProperty，然后实现一个设置子控件Left的逻辑，那么所有子控件都可以SetValue(MyPanel.Left,v)了。（关于DependencyProperty以后再说）
　　用DependencyProperty定义控件属性的缺点就是不方便，如果是GetValue还要将返回值强制转换。即使是Left,Right这样的常用属性，也要通过SetValue与GetValue方式，很是麻烦。相信下一版本的SL会封闭友好的属性接口。当然这仅仅是为了一个方便而已。


      如果大家发现有地方说的不对，还请指正。