Recently we uploaded an RC for our upcoming 5.4.0 release. This release will be NuGet packages only.
We have a number of investments planned in the “request pipeline” area. In 5.4.0 we have a very big set of hooks for reaching into and modifying data as it is being read from or written to the wire format. These hooks provide extensibility points that enable a number of different scenarios such as modifying wire types, property names, and more.
As promised in the 5.3.0 release notes, we now support instance annotations on Atom payloads. Instance annotations are an extensibility feature in OData feeds that allow OData requests and responses to be marked up with annotations that target feeds, single entities (entries), properties, etc. We do still have some more work to do in this area, such as the ability to annotate properties.
Also in this release, we have added APIs to the client to enable the reading of instance annotations on the wire. These APIs make use of the new deserialization/serialization pipelines on the client (see above). This API surface includes the ability to indicate which instance annotations the client cares about via the Prefer header. This will streamline the responses from OData services that honor the odata.include-annotations preference.
In this release we have bundled a few less-noticeable features that should simplify the transition between the Atom and (the new) JSON format. (See also the bug fixes below on type resolver fixes.)
In addition to the features above, we have included fixes for the following notable bugs:
We will blog about this in more detail soon, but we have multiple releases planned that have some level of overlap. We should be publishing a 5.5.0 alpha soon (with additional URI parser functionality for Web API’s OData stack) and in a couple of months you should see a very early alpha of 6.0.0. We’re not ready to say much about 6.0.0 yet other than the fact that it will support OData v4 and will probably have some breaking changes, so we want to get it out there as soon as possible because…
We always appreciate your comments on the blog posts, forums, Twitterverse and e-mail (firstname.lastname@example.org). We do take your feedback seriously and prioritize accordingly. We would encourage you strongly to start pulling down these early bits, testing with your existing services, and telling us where things break, where we’ve gone too far, and where we haven’t gone far enough.
Sometimes when we innovate too quickly and have too many options available, it confuses our clients....
I disagree with the to quick to innovate comment and strongly believe that work of the data services team has changed the time to market of scalable data driven enterprise applications.
With a small team and a clean Unit of Work/Repository abstraction, implemented over data services/entity framework/SqlLite we have been able to produce apps that work in a desktop/web and now occasionally connected windows store/phone apps without any duplication of business logic code (MVP all contained within portable class libraries).
What I would like to see is continuity on the service version consumption from the different runtime environments. Client proxy generation for winPhone and winStore is lagging behind and there mobile bandwidth disposition would really benefit from JSONLight.
The panacea would be to make the all the client bits portable, if not then allow control over the client context/proxy generation via T4. It really is a shame that the OData Client T4 nuget package is not maintained in-line with your releases.
Never the less, your new release looks exciting and I cannot wait to see what we can do with the deserialization/serialization hooks.
Why are both the WCF and WebApi teams both working on OData? Wouldn't it make sense for both teams to consolidate and work toward one implementation going forward. I just am confused about which implementation to use - fearing that in the future, only one will be the winner.
I wonder if it fixes this issue? :
@JimBobPop - thanks for the feedback; I can say that we're definitely headed in the portable libraries direction which will make feature parity across platforms much easier. Also, we do eventually intend for the T4 template to become the primary code-gen experience; prioritization is the only obstacle at this point.
@Todd - you probably won't be surprised if I tell you that's not the first time we've heard that feedback, but I can assure you that we don't think this is a repeat of LINQ2SQL vs. EF. The biggest difference is that L2S and EF were playing in the exact same space without sharing a common foundation. That is not the case with WCF DS and Web API - we are both working off a shared foundation (ODataLib). Currently the products meet two very different needs and have very different flavors of API, so there are absolutely no plans to sunset WCF DS. Our typical guidance is that if you have a LINQ provider and don't need advanced business logic in that particular layer, WCF DS is probably an ideal fit. If you don't have a LINQ provider or have exotic business logic in that layer, Web API is probably a better fit.
@Ross - no, I don't think it fixes that issue. Our server is pretty sensitive to headers and such so it seems like the headers might be getting modified somewhere in the relay. Feel free to e-mail me if you don't get a response on the forum.