Last week a couple venture fund cropped up claiming to be “RSS” focused VC’s. (1, 2, 3, 4, 5, 6, 7) But if you dig a little deeper you’ll realize that they are simply using RSS as a marketing angle (a little disgenuous?). Instead, what they really want to say is that they are a “XML” funds. Funny how an old buzz word like XML is now being replaced with a catchier acronym - the final sign that XML is now fully in the “tornado” phase of adoption.

That had me thinking about broader uses of RSS as a general XML schema because RSS needs to expand its current applications in order for there to be enough companies for these VC’s to fund. As I explore the various application scenerios and use cases I kept on coming back to two extensions that RSS currently lacks. 1. Authentication 2. Push Implementation of RSS.

Now, lots of people has been clamoring for the above things for quite a while (and people are working to incorporate it into the standard as Atom with its more centralized development process has it). Furthermore, RSS can certainly be hacked to do both of these things. But the key here is how to gain broad concensus on the new extension so all RSS “readers” can understand all implementation.

1. Authentication - beyond simple security reasons (seem to be what previous blog conversations focused on), I want RSS authentication to allow me to build products that create personalized feeds AND personalized content modules within feeds. I cant emphasize how much more applications I can think of when personalization comes to RSS. Similarily, the switch from static web pages to dynamically generated web pages enabled much of the web as we know it today. Furthermore, content aggregators like myYahoo seems to have all the leverage and user lock-in due to the fact that personalization comes in the form of selective aggregation. With feed personalization, the power and value add will shift back to the content providers allowing businesses to embrace RSS as a method to build brand loyalty.

2. Push RSS - A little harder to implement and a little less interesting. Still because RSS is essentially a pull protocol (the “S” for syndication makes people think its push but its really not) there lacks a real-time component to RSS needed for certain use cases. For example, if you really want to use RSS for publishing inventory information to your trade partners you’ll need 1) authentication 2) some way of pro-actively alerting trade partner’s interfaces that inventory information has been updated & push data out at the same time. You can ofcourse have your trade partners’ systems ping the feed every 10 second to see if anthing changed, or ping the server with update notice and have it get the RSS feed but I dont think thats very efficient nor very real-time. I dont think push will replace the current system because the current implementation is actually a much more efficient architecture given hundreds if not thousands of subscribers. But for real-time B2B implementation where the subscriber base will likely be low hundreds at the most, the server load issue will not be as acute to simultaneously push out data to subscribers. (Ofcourse a good argument would be why would you want to use RSS to do this in the first place)