Argotic Syndication Framework v. System.ServiceModel.Syndication

Question

I'm investigating the Argotic Syndication Framework, and I'm pretty impressed so far. However, a lot of the current implementation--at least for RSS and Atom--seem pretty comparable to System.ServiceModel.Syndication. Does anyone have any opinions as to one over the other?

Answer 1

Here's my perspective after having followed both paths:

System.ServiceModel.Sydication

• is about 9 times faster than Argotic
• does not have rdf support
• doesn't have support for atom versions < 1
• doesn't have support for rss versions < 1
• fails with XmlException on about 30% of the feeds I give in "from the wild" (this is the deal-breaker for me)

Argotic

• hasn't been updated since Jul 2 2008
• is slow (see above)
• has very good support for all types of feeds: all version of atom, rss, rdf (as far as I can tell)
• is slightly harder to use than System.ServiceModel.Sydication; you need to determine what kind of feed you have before letting Argotic parse it, and then you need custom logic to deal with each of 3 different classes depending on the type of feed. In other words, you need to wrap Argotic before it's useful.

Answer 2

If all you need is RSS and Atom, I would go with System.ServiceModel.Syndication. Barring everything else, there is one significant benefit to using the .NET framework over open source alternatives: Familiarity. If you choose to use the Argotic framework, thats another third-party component that new additions to your development team are going to have to learn (or another skill you will need to look for in your potential candidates.) If you choose to use the .NET Framework solution, you have the potential pool of millions of programmers at your disposal who will likely already know it. Even if they do not know System.ServiceModel.Syndication, it follows the same consistent standards as the rest of the .NET framework, which still provides an element of familiarity to most .NET developers.

While OSS can often offer some intriguing options for nitch problem areas, when it comes to common problem areas, don't underestimate the value of familiarity and ubiquity. A diverse palette of frameworks generally means a much steeper learning curve for new additions to a development team, greater cost of integration between frameworks, versioning and security issues, etc. etc.