Robert Scoble writes
We talked about a bunch of things. I laid out some things that I'd like to see RSS become. I'm gonna talk to Dave about that. For instance, I have a vision of a day when every single Microsoft employee will have a weblog. Now, what happens when you have 55,000 people weblogging inside of a corporation? Well, for one, I want to see weblogs in different ways? Why shouldn't it be possible to see results from a search engine in order of where you are on the org chart, for instance? So, how can you match RSS data up with your domain data that's stored in Exchange and/or other corporate data stores? How about seeing data from corporate webloggers based on revenues? Or other metrics? Also, one thing I miss is being able to tell readers what I think are my most important items.
For instance, I have a vision of a day when every single Microsoft employee will have a weblog. Now, what happens when you have 55,000 people weblogging inside of a corporation? Well, for one, I want to see weblogs in different ways? Why shouldn't it be possible to see results from a search engine in order of where you are on the org chart, for instance? So, how can you match RSS data up with your domain data that's stored in Exchange and/or other corporate data stores?
How about seeing data from corporate webloggers based on revenues? Or other metrics?
Also, one thing I miss is being able to tell readers what I think are my most important items.
A number of these features have nothing to do with RSS, although I've seen several people claim otherwise. Scoble's post is just the most recent. Lots of people (including myself) see RSS news aggregators as being a step towards building a universal information aggregator. The closest thing to universal information aggregators that exist today are Personal Information Managers like Microsoft Outlook. At it's most basic description, Outlook is a mail reader meaning it nows how to use SMTP to send messages from one server to another; and how to retrieve messages using either POP or IMAP. However over time Outlook has evolved into my primary interface to accessing information about people I interact with in a daily basis. I usually ask Outlook questions like
All of this functionality is exposed in a consistent user interface and it is hard for me as an end user to tell whether SMTP, IMAP, POP3 or whatever else is being used to service these requests. This is the same direction I believe people will want to go with news aggregators especially when I read some of the forward thinking feature requests that come from people like Marc Canter and Ray Ozzie. Even though at its most primal, an RSS news aggregator is a client that polls for messages in RSS format using HTTP there is a lot more functionality people want from want from clients.
The obvious (and in my opinion the wrong) way to solve these feature requests is add a lot of extra yet optional functionality to the base protocol, RSS. However using the Outlook example, it is clear that one doesn't need to completely go this route to solve the problem after all not all 10 of the pieces of functionality I described above have to do with SMTP (although a lot do).
There are two reason's why I find WinFS interesting when it comes to build a universal information aggregator. Both of which have been pointed out by Mike Deem, the first is that WinFS will be an item store which means that it will be possible to store abstract concepts such as "person" or "contact" on your file system as opposed to just concrete files such as buddylist.xml. The second is that WinFS's schemas play an even larger part in making WinFS what it is. The idea that there will be a common schema for “Person“ and “Document“ and “Album“ that can be shared, and extended, by thousands of Windows applications. The really important thing is having a shared concepts and schemas for both local applications and globally networked applications. Being able to actually store a person's contact info, weblog posts, mail messages, schedule and more on the file system and have these all linked together without the limitation that they all have to be the same file or that one must tie their client application to a database products makes developing a lot of the functionality I get from Outlook or that Scoble would like to get from an RSS aggregator much simpler. Being able to retrieve a calendar event from the Internet as XML either via some XML Web Service or HTTP GET then map that to a local concept of a calendar event on my machine which could then be used across applications would be very useful.
Of course, WinFS is currently at a stage that people like Diego Doval would call vaporware so this is just supposition on my part from reading Mike Deem's blog and conversations we've had as opposed to stuff that actually will ship in a future version of Windows. Even then the programming model may leave much to be desired, e.g the following code snippet from Mike Deem's blog
For example, to find all the people who live in the New York metropolitan region, you would write code like the following: Person.FindAll(“IncomingRelationships.Cast(System.Storage.Contacts.HouseholdMember).Household.OutgoingRelationships.Cast(System.Storage.Core.ContactLocations).Location.MetropolitanRegion = ‘New York’“ );
For example, to find all the people who live in the New York metropolitan region, you would write code like the following:
Person.FindAll(“IncomingRelationships.Cast(System.Storage.Contacts.HouseholdMember).Household.OutgoingRelationships.Cast(System.Storage.Core.ContactLocations).Location.MetropolitanRegion = ‘New York’“ );
So needless to say it isn't a slam dunk that "WinFS will solve all our problems" but I think the general ideas and functionality it brings to the table could prove very useful. In the meantime, I plan to hack the features I believe should be in a universal information aggregator client into RSS Bandit and will work with likeminded souls in moving the state of the art in that direction.