MacOSX has had their Core Image API for a long time which abstracts you from the GPU. Now Adobe has stepped up to the plate by introducing a preview of a new toolkit who's main technology is a new programming language, codenamed "Hydra", that enables the creation of filters and effects that can be compiled down to run on the GPU (if GPU is not available, it falls back to CPU). Here's their tutorial that gives an example of how to write a filter with Hydra. There's also a gallery of sample filters available here. Kudos to Adobe for attempting to bring this technology to the mainstream.

So, the next question is, when are we going to see something similar for WPF and Silverlight? Sure WPF has BitmapEffects, but as anybody who is familiar with the BitmapEffects API knows, they are themselves completely CPU based and, in turn, also force whatever visuals they're applied to be rendered on the CPU. This pretty much renders them a no-no if you're trying to create a really fluid, animated UI... that is as long as you expect to have high frame rates.

People have been asking for this capability since WPF was announced.  Where you at Microsoft? :) If only they documented MILCORE, maybe someone could tack it on for them...

I'd been thinking about this topic since I saw the new interface. Basically, after seeing the screen shots, I thought to myself that if the new Zune Windows client software was not written with WPF, Microsoft will have made a huge mistake by once again not backing one of their own technologies as a viable platform for developing a real world consumer application. Knowing the type of data this kind of app pushes around, the behavior in the v1.0 client today and looking at the new screen shot, that's an app that screams WPF.

So, yeah, I was going to just wait and see once I downloaded it, but I got curious and started to look around to see if there was an answer to the question already. Sure enough there is. Unfortunately though, it's not the one I wanted to hear. In this response to a forum thread about the new Zune client, Charlie Owen, Program Manager for Windows eHome (i.e. the Media Center team), states that it is instead based on the Media Center UI framework.

Let's step back for a second here. WPF has been pitched to us as a pillar of the next generation Windows experience since the announcement of the WinFX framework (later renamed .NET 3.0 *sigh*). For all intents and purposes it is by far one of the best frameworks I've ever seen for building rich client applications. Forgetting the flashing lights type stuff for a second, even just the layout and data binding engines alone make it one of the best platforms to work on. Yet when a group of Microsoft developers (remember they took the development in house this time around) sat down at a table and considered their choices for writing the next version of the Zune client they actually decided they'd rather use a variation (Charlie's words from the post) of the Media Center UI framework instead. Think about that... they didn't just use the Media Center framework, they actually made changes to it to suit their needs... and they did that rather than pick the fully baked platform of WPF.

End result so far as I can tell? Time wasted creating a proprietary framework. Opportunity to show the world that WPF rocks the house wasted. To bad. So sad. I hope someone out there can point out a positive aspect of this choice. I don't think being able to run the interface on Media Center extenders, assuming that was the main point of this, is a good enough explanation because you can write WPF based Media Centers today and, while they don't currently perform as well as a native MCML application, they perform well enough to cover what Zune would need to do AFAICT. Maybe the fact that Media Center forces WPF based apps into the Internet Sandbox is the problem? Why in heck they crippled them this way to begin with is beyond me, but if that were the issue wouldn't it have made more sense to invest in a joint project to lift that restriction for trusted/signed applications or something?

For those who may not already know WCF that well, FaultException is a special type of exception class that exists as a way for those of us who are writing service operations that need to throw errors to indicate to those who are extending the WCF stack that "hey, I want the details of this exception to be passed through to the client". The whole purpose of FaultException is so that if something like a database statement fails unexpectedly deep inside the implementation of your operation, the details of that exception, which may include sensitive SQL syntax or schema object names for example, will not make their way back to the client. Instead it will be caught and replaced with generic details saying that something bad happened on the server side.

Out of the box the various implementations of channels, behaviors, etc. that come with WCF understand the semantics of FaultException and process it correctly using the logic explained above. In fact, the ServiceDebugBehavior even includes a property called IncludeExceptionDetailInFaults to disable the swallowing of non-FaultException details so that they are returned to the client. This is great for debugging and QA environments, but obviously it's a setting you want turned off when going to production.

Unfortunately it seems that System.ServiceModel.Web's support for FaultExceptions is lacking. Assuming a production environment where IncludeExceptionDetailInFaults is turned off, for any webHttpBinding endpoint, if you throw a FaultException from your operation, that exception is returned to the client with an HTTP status of "400 Bad Request" and the body of the response will be an HTML page that tells you to check the "server log for details". The Reason of the FaultException will not be included anywhere in the the output. The encoding used doesn't matter, the result is the same for both POX and JSON. In fact, the only time that the reason text is properly returned from a WebHttpBinding is when you use the EnableWebScriptBehavior which is what adds support for the specific semantics of JSON requests for ASP.NET AJAX clients. This is actually a "good thing" considering that ASP.NET AJAX 1.0's ScriptHandlerFactory that adds support for JSON calls to ASMX based web services completely swallowed all exception messages unless you turned customErrors="Off" for your whole web application which is of course a really bad idea for the same reason you wouldn't want includeExceptionDetailInFaults="true" in a production environment.

Next, let's talk about FaultException<T> and fault details. FaultException<T> is a special subclass of FaultException that you can raise to include details, in the form of a data contract, that you want returned to the client beyond the standard Reason, Code, etc. of a FaultException. This is basically the feature that allows you to return structured information about your fault rather than shoving everything into the reason text and expecting your clients to parse that string somehow. System.ServiceModel.Web does not appear to support this concept right now either AFAICT. So if you were expecting to see these details returned in the body of the response rather than some string explanation, you're also SOL.

Finally, let's talk about the HTTP statuses that are returned when exceptions are raised out of operations exposed via the WebHttpBinding. Currently any exception thrown will result in a "400 Bad Request". I believe is the perfect status to return when there is a FaultException thrown because a FaultException definitely means there was something wrong with the logical operation. However, it I don't think it's the right status to return if a non-FaultException is raised. Instead I think a "500 Internal Server Error" should be thrown in that case. The difference in the status would be to help differentiate between a logical error with the request (a FaultException) and an unexpected error while processing of the request.

For an ongoing discussion of this topic, please check out this thread in the WCF MSDN Forum.

I've been doing a lot of digging around System.ServiceModel.Web lately and have come across a subtle difference in the way the XML is produced for POX endpoints when switching between BodyStyle.Bare and BodyStyle.Wrapped[Response].

The quick and dirty explanation, if you're using Bare and you return a DataContract with Name="Foo", the name of root element returned will be "Foo". If you're using Wrapped however, the root element will be a wrapper element named "<YourMethod>Response" and that will contain a child element named which will be name "<YourMethod>Result" instead of "Foo". For full details, including sample XML output, check out this thread I started over in the WCF MSDN forums.

I have been playing with this System.ServiceModel.Web for about a week now trying to get real world prototypes together and, in addition to having a hard time understanding some of their design choices with regards to how/where they plug into WCF, I have come across at least two major limitations. I'll start with brief descriptions of limitations and then elaborate below:

1. You cannot mix WebInvoke decorated methods that specify a UriTemplate with the enableWebScript behavior that is meant to provide compatibility with the JSON protocol (i.e. application/json) that ASP.NET AJAX uses. See my post here on WCF forums.
   
2. You cannot use DataContract types as parameters for UriTemplated methods because the UriTemplate parsing engine doesn't have an understanding of assigning portions of the URI to properties/fields of your DataContract instance. See my post here on WCF forums.

#1 elaborated:
What this means is that you cannot expose the same WebInvoke decorated ServiceContract via different webHttpBinding based endpoints the way you would like. So, for example, I want my service to be accessible not only via application/json requests, but also simple REST requests that return POX. Because of this limitation, I cannot do that.

This basically flies in the face of everything that is good about WCF by tying your operations to a particular message serialization/addressing implementation. The saddest thing is, I don't see why this has to be broken. The enableWebScript behavior should just cause the UriTemplate functionality to be ignored.

#2 elaborated:
What this means is that you can use strings, ints and all the other intrinsic .NET value types for your operation parameters, but if you want to use your own custom DataContract based type, you're SOL. Imagine the case where you want to pass in some paging information to various operations. So you design a data contract called PagingDetails that has properties like PageSize, PageNumber, etc. Now you want to make this operation accessible via a simple REST URL. You would expect you might be able to define an operation like this:

[WebInvoke(UriTemplate="MyOperation?SearchText={searchText}&PageSize={pagingDetails.PageSize}&PageNumber={pagingDetails.PageNumber}")]
public List<string> MyOperation(string searchText, PagingDetails pagingDetails);

You would hope that the UriTemplate infrastructure would understand the dot-notation in the named variables and map those values to the pagingDetails parameters instance's properties, but alas it does not and instead just complains it can't find a parameter named "pagingDetails.PageSize". Again this limitation seems to fly in the face of the very basis of WCF where DataContract is very much a first class citizen.

In conclusion, I'm sad to see that some of the design decisions behind System.ServiceModel.Web have crippled it in this way. Essentially the only way I can think of to work around these limitations is to design completely separate service contracts with the same method names/signatures so that your implementation class can fulfill both service contracts operations with a single implementation of a method and then you still need to expose separate endpoints with the proper configurations. The other option is to forgo using UriTemplate at all and just settle for XML POST requests to your POX services.

Wow, this is a pretty major announcement. They're going to be making the source code available for a significant portion of the BCL, ASP.NET, ADO.NET, WinForms and WPF from day one. Eventually WCF, WWF and LINQ will be available too.

Wow.