Making Feeds Friendly
The goal of Astoria in V1 is to easily expose a data source using the REST approach to the web (with support for concurrency, versioning, auth, etc). In general, the way we think about serialization formats (ie. how we represent entites on the wire) is that they are a tool and an application will select the best tool (ie. serialization format) for the job. For example, AJAX developers will likely opt to interact with Astoria services using our JSON serialization format while .NET developers may choose AtomPub since our .NET client library uses that format under the covers. In V1, Astoria supports using the AtomPub and JSON formats as a general purpose data exchange representation and has fixed requirements regarding how an entity is to be represented using the formats. While this works well for a number of app scenarios, we’ve received feedback regarding use cases (one example being mashups) where an app/tool/etc is written to consume general Atom feeds and can then make assumptions about the data given (ie. what the title is, who was the author, etc). This area of thinking/exploration (uses of feeds in the wild and how to make Astoria’s feeds just work in certain scenarios) has been dubbed by our team as “Friendly Feeds”.
One of the specific scenarios we’ve discussed is a mapping site (ie. virtual earth, etc) which accepts feeds as an input and then displays the feed information on the appropriate spots on the map. In this scenario the mapping site would pull metadata from the well known Atom elements (title, author, content, etc), but also needs to locate geo information to be able to determine where on the map to place the data. For this we’ve seen some feeds start to embed micro formats in feeds such as georss. To make this more concrete, imagine being able to drive the example shown here via an Astoria feed.
We are still thinking about this space, but right now the high level goals we see as necessary for such a feature are listed below. What do you think?
Goals:
· Enable feeds to be easily customized such that a generic feed viewer can render an Astoria feed
· The feed customization approach could be applied to feed-based formats other than Atom. JSON serialization will not support this type of “Friendliness”
· Enable entity properties to be serialized as microformats within a feed
· Serialization customizations “just work” with V1 data service client libraries wherever possible. Changes that require a protocol version number increase should be explicit and off by default
· The ADO.NET Data Services client library (for .NET Fx and Silverlight) would be able to roundtrip a “Friendly Feed” in the same way the client roundtrips data in Astoria V1.
· We would also teach our code generation tools to understand such “Friendly Feeds” and generate the appropriate clients.
· It is NOT a goal to make ADO.NET Data Services into a blog server — there are better domain-specific tools for that
Oh, I almost forgot……a nice benefit is that with this feature Astoria Atom feeds could likely be made directly viewable in IE. Folks who have inspected AtomPub-based feeds in web browsers today know what I’m referring to.
Below is a short video we recorded that discussed this area as well. Andy (Astoria Dev Lead) got a new camera and came up with the idea of adding these videos. Let us know what you think of having short video snippets such as this to accompany our design notes as we blog them….
Astoria Design Walkthrough: Friendly Feeds Part 1
In a future post, I’ll include some specific examples to show how we will enable this in our server runtime and client libraries.
Cheers,
Mike Flasko
ADO.NET Data Services, Program Manager
This post is part of the transparent design exercise in the Astoria Team. To understand how it works and how your feedback will be used please look at this post.
Light
Dark
0 comments