Last week we put up a sample named WCF RSS Toolkit on wcf.netfx3.com and I posted a sample service using it here. Since I wrote most of the toolkit’s code I thought I’d talk a bit about its goals, design and the future. There were two primary goals for this sample:
Note the “and” not “or” in #2, meaning the same service implementation can be exposed as RSS, Atom, or any other format simultaneously. If you know WCF, you’ll know this means generating multiple wire formats (RSS, Atom, whatever) from the same contract which can be done with some extensibility. The key is to not rely on the contract projecting the desired info set, rather to transform whatever info set projected by the contract to the desired info set. That transformation would be different depending on the desired wire format.
To make it easier for developers to emit RSS and Atom, I defined a DataContract with some of the commonly used RSS/Atom data and I defined a transform from that DataContract’s info set to RSS and another transform to Atom. All of this is pluggable/replaceable: You can use your own DataContract if you like, the transforms will transform what they recognize and copy the rest out as extension elements. You can also plug in your own transform to support new formats. Since it’s source, it’s also customizable so you can modify the DataContract and/or the transform if you don’t like how I make DataContract members to RSS/Atom elements.
There was also the HTTP GET part of the equation. WCF’s HTTP transport supports GET out of the box but there are other places in the stack that need to be extended for the scenarios I had in mind. For example, dispatching to the right operation based on the path segment following the endpoint’s address in the request URL. Also, parsing the request query string and decoding parameters from it. And of course, supporting ETag and Last-Modified HTTP header. All of these are commonly needed in RSS/Atom scenarios and when we do build RSS/Atom support into WCF, we will have these features. For the sample however, the first two are included in the sample but the last one isn’t. The good news is that the WCF HTTP transport gives you full read/write access to HTTP headers via the Message properties HttpRequestMessageProperty and HttpResponseMessageProperty so you could build ETag support on top of the current WCF bits. In fact, one of the benefits of having the RSS toolkit sample source code is it gives you a starting point that you can take and modify with ETag support and other features you want. You can even publish you modified sample for the community to learn from and use.