Like almost all recent videos, this one does not work. It is continually disrupted by the need to buffer more data. Channel 9 has always been poor functionally because it was very difficult to find anything old. But the video used to work fine. No more.
As far as I am concerned Channel 9 has become an embarssment to Microsoft and everyone associated with it. Note that the 10-4 episdode 29 Workflow Web Services Video is the one recent one that I have tried which worked without problems.
Well perhaps you should get excited about the decline of channel 9. I don't know if it is actually using Silverlight. But I thought Silverlight's great virtue was being able to adjust banwidth usage to what was available on a connection. In contrast channel
9 has stopped working over a 700kbps DSL connection unless I go to the trouble of downloading the video.
This video is another instance of a common recent problem on channel 9. That is a video that is not usable over 700kbps DSL. Generally, the quality of channel 9 usability is erratic at best. Increasingly, I am finding it not worth making the effort to
use it. Certainly it has become a poor advertisement for Microsoft quality.
A mess has been made of posting this video. Anyone who wants to put the best foot forward for WPF and VS2010 should start out by finding someone who can post a usable video. This presentation is an embarassment.
The reality is that there probably would not be both VB and VC# except that VB was so widely used in the Microsoft installed base and C was the industry standard language. But both languages have more than enough paying customers to justify continuing work
to maintain and enhance them. In the near term, the enhancements are likely to be mostly of interest to language enthusiasts. But there is no particular reason why an enhancement is more appropriate for one language or the other. When a customer actually
decides they do want to use one of these enhancements, they should not discover that they need to bring a new language into their environment to use it. They are paying enough to support Microsoft doing the work of getting those enhancements in both languages.
The configuration dialog is a real downer. Trying to force people to use the settings Microsoft wants is a disgrace. If I see the dialog again I may think about switching to Mozilla and I am a fairly hard core Microsoft supporter.
As best I can tell, it is still the case that VPC does not work on Windows Vista Home Premium. That point should be called out any time that instructions are given that depend on VPC. The other reality about this CTP is that very little of the .net4
technology is in it yet. If you are interested in TFS or specifically in Visual Studio, it may be worth the effort. But I would not have bothered with the large effort of downloading it if I had realized how little was in it.
I am happy to hear confirmation that you plan to put the sessions online. It was actually done for the last PDC. But only a few weeks after the fact apparently through some kind of special effort by someone in Microsoft. I found those presentations
very useful and I am looking forward to the ones from this PDC.
Adobe Photoshop is one of the few commonly used client applications that actually has some prospect to add real value with the extra memory that 64 bit clients make possible. The fact that they are just getting around to 64 bit support should tell you
something about how little real value most customers can expect from all that extra memory. Of course, once all the compatibility issues for 64 bit have been dealt with, there will be no reason not to use 64 bit. But only users of very selected applications
are going to see any real value from it.
As Charles points out, many core does not come for free. Few companies are going to invest in parallel processing unless they are going to be able to show their customers some real value from it. People who think advances are adopted just because technophiles
think they are great should take a look at the history of IPV6. Today, many core also does not come for free from a power perspective. People who expect users to burn that power just to make some lights flash faster should take a look at the history of the
The reason for a single UI thread is very simple. The use of a single thread results in no problem in synchronizing any of the message processing involved in presenting the UI. It is far from obvious that there is any problem with this situation as long
as an application does not try to do some significant synchronous background processing on the UI thread. It is also the case that .net provides functionality that makes the use of a background thread easy for background processing in either a WinForms or
a WPF environment. In practice with WPF it is easy to use three threads that could be running on three processors for the UI. Those threads include the standard UI thread, the render thread, and a background worker thread. Charles can rant on all he wants
about the wonders of multicore. But it may take him a while to find the client workload that actually has any real requirement for more than two or three cores.
As far as Vista stability goes, it has been very good since I started using it during the RC0. I have had two or three blue screens in total during that time.
I don't think Charles got the value proposition quite right. Presumably, the value proposition to Microsoft is writing Silverlight applications with Visual Studio on Windows. Presumably nobody is going to offer a development environment on the Mac.
The value to the developer from having Silverlight applications run on IE, FireFox, and Safari on Windows and Mac is getting reach with their applications. Presumably this feature is essential if you want to attract developers to proprietary frameworks that
run over the web. The situation with Moonlight is more interesting. Presumably, Mono will have its own development environment and also the potential to run Silverlight applications on the Linux desktop. It will be interesting to see how that works out
and what kind of mixing and matching there is between Microsoft developed tools/appllications and those developed on Linux.
For practial purposes, SOAP is a superset of REST. The key limitation of REST is the operations which are limited to what HTTP supports. Like anything else even those limits can be hacked away and actually are by FORM style web processing. But REST
sticks with a small number of basic operations on addressable resources, get, put (insert), post (update), and delete. These operations are the same ones used to access relational databases. The alterative that used to be in much more favor is a distributed
object model along the lines of DCOM where you have network communication that involves remote references to objects and complicated state models between objects that cooperate across the net. For all the noise, Microsoft's strategy seems strongly in tune
with the REST model. You see that in the way that LINQ, ADO.Net Data Services, and the Entity Framework operate. Data is separated from behavior, modeled as sets of entities, and made network addressable. The operations on data are those used by REST and
also by traditional databases. So the decision between REST and SOAP will mainly revolve around the particular environment that you are working with and the supporting function that is easiest for you to use.