Wish: Subscription Abstraction Layer

RSS.NET and Atom.NET[1] are great, but they sure could use an abstraction layer. I'll bet the same conditional logic has been written hundreds of times, but I haven't found anywhere that it's been abstracted out as a standalone library. Think ADO.NET - it's a general data access framework that allows any data provider (SQL Server, Oracle, DB2, Text, write your own) to be accessed as generic interfaces (IDataReader, etc.).

A Subscription Abstraction Layer (SAL) would simplify a few things:

  1. Generic access to subscription providers
  2. Simplified extensibility for new or changed subscription formats
  3. Offer a Persistance layer which would store data to any provider for which a provider had been written. Of course, everyone's datastore would be diferent so the providers would mostly serve as samples, but I'd just need to fill in my stored procedure names or SQL commands. This could potentially use the Enterprise Library, or could just implement the informal DAAB 1.0 DataHelper interface.

I'm hoping someone has already written this and I've just Googled poorly. I'm guessing there are parts of this in many weblog systems and aggregators, but I'd really prefer a distinct library. If it's not out there, I'll probably write it - does this look like an okay design?

IFeed IFeedCollection IPost IPostCollection Additional generic interfaces  ... 


Subscription Abstraction Layer (SAL)

Persistance Provider Interface
MS SQL
Firebird
SQLite
...

RSS.NET

RSSFeed
RSSChannel
RSSFeedCollection
...

Atom.NET

AtomFeed
AtomChannel
AtomFeedCollection
...
Additional Subscription Providers (Atom 1.0, RDF, NNTP, etc.)

A really lame cheat would be to just XSLT RSS to Atom or Atom to RSS and treat them all as one specific feed type, but I don't think I can bring myself to do that.

[1] Anyone know if / when Atom.NET will support Atom 1.0?

3 Comments

  • You've come across a very good idea. Unlike ADO.Net where you have to specify the provider, it would be cool to have a simple way to import and display feeds using some level of automatic detection. Don't Atom, RSS1, RSS2 and probably others serve out pretty much the same type of fields (link, description, title, date)?



    I'm new to ASP.Net, I clung to old ASP for dear life but I have already had some fun pulling in RSS feeds and using the XSLT method to display that feed. It seems like such a clean way to do it. So why would using XSLT to first convert the feed to a common data structure (like Atom to RSS or even RSS & Atom to a more generic structure), then taking that data and giving it back to the application to do with it what it will. Well why would that be so bad? It would also be cool to build in a way to cache the data for a specified amt of time.



    It could look something like this



    myReader = myFeed.open("provider:auto; server:url(feed.rss);")

    while myReader.Read()

    response.write myReader.Item("Title").Value

    end while



    Or some better thought out variation of that. I'm sure your better then my at .Net so you could probably even find a way to make your control work with some .Net server controls.



    It would be nice to have a "ready to go" solution for all your RSS needs.



    Although.. Won't people settle on a type of syndication feed eventually? What are the pro's and cons to Atom, RSS1, RSS2, etc..?



    I'm a man of many questions. :-D

  • Actually, I found lots of RSS/ATOM feeds not complying to formal XML requirements, thus not able to be parsed directly by XML parsers. Even Microsoft RSS feeds lack XML headers. I doubt that the new RSS framework for Vista/IE7 will provide any help to this issue...

  • I have written a layer in C# that sits ontop of RSS.NET and ATOM.NET. Calling it an abstraction layer is a bit of a stretch.



    What I do internally is map the ATOM.NET fields to to the same names that RSS.NET uses, since I wrote my app to use RSS.NET first.



    If you want to proceed with an abstraction layer framework, I would be interested in working on it.

Comments have been disabled for this content.