hak

The feature allows the user to choose any web page marked content so that he can get live updated of the content separately from the browser. And here comes the point where Web Clip is well better implemented than Web Slices. Web Clip automatically transform the part of the subscribed web page content to a widget (Microsoft calls that gadget) which is permanently updated by DashBoard (the centralized widget engine in Mac OS X). The nice thing is that the user does not need to bother with notifications inside the browser to view the most recent updates of the content, every time, he views it, he can be sure that he has the latest update. Also he does not need to launch any browser to view it, as the web page marked content gets integrated in the widget environment Dashboard and to view it, only accessing Dashboard is necessary. In other words you get your subscribed  web content at any time you need it. And the engine is very powerful because any portion of a page can be transformed to a widget because Dashboard uses the webkit engine.

Sad that such channel9 videos tries to describe an innovation which is not, and sadly credit to where the idea comes from is not mentioned. It ok to take an idea from somewhere else, but don't make it sound as a Microsoft's innovation or new idea.

@aL_ 

As it was said, Mac OS X is a 64 bits OS, and the amount of work needed to port an App to 64 bits depends on the nature of the App. So saying that developing a 64 bits application is difficult in not correct, it depends on the type of application. 

So if you got a Cocoa application or an X11 (Xwindow) application, no problem, porting to 64 bits is easy to do. You application can call any other modern APIs as OpenGL, Quartz, Core foundation, Quicktime, Core Audio, Core Image (you name it, all the great stuff in OS X), they are all 64 bits safe. So for any Cocoa application, the port is easy. For any Unix X11 application, the port is easy.

Now comes the problem of Carbon. Carbon is the legacy APIs from the original Mac OS which was cleaned, enriched and put in OS X in order to allow developers to port easily existing Mac OS applications to Mac OS X. Carbon is a procedural API, it served well the mac, and its transition to OS X, but it seems that Apple wants people to move on, the legacy APIs in Carbon are not worth any more any further development as Apple moves forward. At some point Mac OS X needs to drop this legacy API. A good occasion to do that is the transition to 64 bits and Apple recognized that. Even though a working implementation of a 64 bits Carbon was available in the first betas of Mac OS X leopard, Apple decided to drop the support of 64 bits in Carbon in order to encourage developers to move to Cocoa.

So what's the result for developers having a Carbon application that they want it to be 64 bits? Well they need to rewrite the UI code. That's there where the precisions are needed. Developers need only to migrate their UI code to Cocoa as only the UI related APIs in Carbon are not supported in 64 bits. All the low level Carbon C APIs (also commonly used by Cocoa applications) are available in 64 bits. So basically porting a Carbon application to 64 bits means migrating the UI code to Cocoa. That's not bad, many very big code has already done that, like Mathematica or Cinema4D. Note also that some applications relying on QuickDraw for the drawing should also migrate to Quartz instead as QuickDraw is anyway a depreciated technology, hence not supported in 64 bits.

To summarize, there are already a lot of Cocoa applications out there, the comment on the video made it believe that any applications out there is not Cocoa based and that you need to switch to Cocoa to have a 64 applications, but that's not the point as many applications are already Cocoa based and very easy to port on 64 bits. This is also the case for all Unix application which rely on X11, they can be ported to run on 64 bits very easily because Apple builds a 64 bits safe X11 implementation.

Applications using Carbon for their UI should use Cocoa instead to run in 64 bits, this can be a bigger effort for some developers like Adobe which has a very old code base relying on legacy APIs, but in the long term it will be very beneficial for Apple because it won't need to support a old API, that makes the OS less complex and easy to change.

The example of Adobe Photoshop is a good example of an old code base which will need some work in order to migrate to Cocoa. That's why the next version of Photoshop will be 64 only on windows, the mac has to wait for the following version. But here again. in the long term it will be beneficial for Adobe and the mac that Photoshop get cleaned from his old legacy code so that it will be able to move forward more easily. 

Also another mistake in the video concerns Adobe Lightroom. Lightroom is a cocoa application, and the latest version (the version 2.0) run in 64 bits on mac.