Oh yes. The WinFS Post. Dare linked to a previous post of his while commenting on Microsoft focusing on vision, rather than shipping, which reminded me that I hadn't gotten around to writing about it.
Here's the link to the more interesting post, and if you've been living under a rock and don't have a scooby-doo what I'm talking about, here's a great Wikipedia article about it all.
I didn't get to play with any actual bits, so I'm not about to shoot my mouth off about the technology, but I loved the concept. I was very disappointed to see WinFS go. It was the most exciting of the original Three Pillars of Longhorn (WinFS, Indigo and Avalon).
On the surface, it was all about search. I think we've nailed that one without needing WinFS. There were some advanced searches that we were promised (as Wikipedia says: "the phone numbers of all persons who live in Acapulco and each have more than 100 appearances in my photo collection and with whom I have had e-mail within last month"), but I wouldn't bet against Windows Desktop Search being able to handle something like that, especially when you see the surprisingly-off-by-default natural language search.
I think a lot of people unfairly dismissed the more interesting part - the data store. To me, this was the killer app. WinFS stored any data you wanted it to, in a structured manner, with relationships between items and properties and allowed you to search over the lot. This was huge.
It had a bunch of built in schema, so you could store contacts, emails, IMs, documents, pictures, videos, music and more. But as Dare points out, many people felt there was a chicken and egg situation. Most apps already had massive investments in their own data store (e.g. Outlook) so why would they throw that away and migrate to WinFS?
As I understood it, the architects of WinFS had already thought of this, and you could promote metadata from your custom data store into WinFS, and get back notifications when the WinFS data store changed. Bingo. No need to rewrite your app.
The really big thing about the data store was that it totally blew open the data silos. It effectively normalised all data formats. Yes, I can search for all contacts with Windows Desktop Search, but once I've got the results, there's not a lot else I can do, because some are stored in Outlook, some in vcard files, some in Vista Contacts, some in IM, etc. With WinFS, you just have a contact. You manipulated the WinFS Contact datatype and saved the changes back. That's incredibly powerful.
This post by Brandon Paddock of the WDS team is great - read the comments. He points out that WinFS would still have to store music in different formats - WMA, MP3, etc - so is this unified API viable, or just a little too idealistic?
Even if the unified data store is a step too far, WinFS is still a killer app from a dev point of view. Just about every app you build has to have local storage, and you always have to roll it yourself. You've got a whole heap of options, none of which are ideal. Xml files means reading the whole of each file into memory (like Sharpreader and RssBandit do - hence the large memory footprint), you could use a database, such as Access, SQL Server (Express), SQL Server Everywhere, SQLite, etc. But these have their own limitations - is the data you want to store suitable for a database (RSS feeds or email messages in a SQL database?) Is client/server appropriate? Is an in-process DB robust enough? You could even roll your own solution, which is fraught with peril. Or you could just let WinFS worry about it and get free searching to boot.
Ah WinFS, we hardly knew you...