Skip to content

I’m not sold on WinFS.

by Brandon on August 29th, 2005

First off, let me say that I am very impressed with the work the WinFS team has done and that they’ve already won a great deal of respect from me.  That said, I’m not 100% sure I see the need for their product.  This opinion is certainly not set in stone, but from what I’ve seen and what I understand so far… I’m not sold.

Why is that?  Well maybe it’s because I watch videos like this one and I think… why is that different from what we already do?  You can tell that these guys are super fired up about the fact that they’ve matched parity with the basic Windows filesystem.  And I’m sure it wasn’t easy, and as a developer I was impressed.  But as a user I thought, “Great.  You have parity with the current system.  Now what are you offering me that makes your effort worth while?”

And that’s where WinFS runs into trouble, in my mind.  I see it as a great technological feat, but one with few or no rewards.  I think Everything I saw so far from a user perspective can be done today, without WinFS.  Some of it hasn’t been done… but it could be.  I sat here watching the video with some other members of my team and several times one of us would say “Looks like our stuff,”  or “Yeah, we could do that.” 

The way I see it, the fundamental difference between WinFS and the Windows Desktop Search “platform” is that they embed the actual file data inside the database.  Whereas, we have a database with all of the item’s data, and then we have a reference or URL to the item (be it a file, an Outlook e-mail or contact, something from Thunderbird, etc). 

The other differences are just implementation details.  They implement their types as CLR-types.  That’s pretty cool, but I don’t see why we couldn’t do that in theory

But as a user AND as a developer, I don’t really care where the actual data is stored.  I don’t care if it’s in a file under some folder.  I don’t care if it’s a MAPI item stored in a PST or on a server.  All I care about is that I can query the system for this data regardless of where or what it is, and sort, group, view, or manipulate those results however I choose.

So in the video, they demonstrate an app that displays all your “stuff” on a timeline, and divides it into bands based on tags or properties.  You could do that today using our WDS APIs.  They show creating “relationships“ between a group of photos.  We do that today in Vista beta 1 with tagging.

They show an X1-like app that lets them filter results.  So they do a search for all the meetings he’s had in the last 30 days.  We can do that today.  Then he gets a list of all the attendees from in that list (meetings from the last 30 days).  We can do that (even if it’s not completely exposed in our UI so far) – and Vista does it all over the place.  Then he saves the query.  We can do that today.

Now, the next thing he does is cool, and it’s my favorite part of the demo.  He starts a new query for emails, and filters the From field by the results of that original query (people he’s met with in the last 30 days).  So now he has a list of emails from people he’s met with in the last 30 days, using the saved query from before as a source for the From filter.  Sweet.

But again, I think this is something we could do without WinFS.  In fact, I’ve already started some discussions around here about different ways that we could accomplish these same goals.

The key is that WinFS and our index are both databases.  And we have access to the same metadata that they do.  The only difference I see is that when a program asks us for the result file or item, we give them a pointer to it, instead of actually returning the item directly.  That… and we can index things that aren’t on the local hard drive. 

We can index objects without having to consume them entirely. 

We can go out to the object and say “Give me all the useful information you can about yourself” – and then remember it.  If something changes, it can tell us.  Why would I care if the object actually lives in the database.  Why not let Outlook store data where it wants… in PSTs or on an Exchange server.  With something like WinFS… you’re trying to get Outlook to use the WinFS way of storing items.  And if I want to index e-mail that’s on a server, my guess is that the server has to have its own WinFS implementation for it to federate queries to.  But what if my server doesn’t run WinFS?  Can I plug in a protocol handler and have WinFS pull just the metadata to my local machine?  What if my e-mail server runs Unix and can’t run WinFS?

For all I know, they have good answers to those questions

I just haven’t heard them addressed yet.  And it’s not like they’re pressed for time… It sounds like they have plenty of time left to convince me that my all my team’s work is going to be obsolete =)

Comments are closed.