Arian Kulp's Blog
opinion, insight, and occasional code

The Demise of WinFS

Monday, June 26, 2006 9:11 PM
Everyone in the know seems up in arms about the shelving of Microsoft WinFS.  I'm pretty upset about it too.  I've been playing with it off and on since the first build I got my hands on.  It's slick.  Very slick.  This "productizing" thing is annoying.  Do they really mean "profitizing?"  Plenty of people think that this is the case.  According to the original post on the WinFS blog, parts of it will be canibalized for SQL Server and ADO.NET.  The idea of less structured data in SQL Server is certainly important and needs to be there, but this is hardly a replacement for WinFS.  Adding features to ADO.NET (Entities, I think the feature is called) is also good, though the concept of objects in ADO seems to be what LINQ is about.

I've played with WinFS since early (pre-Beta) builds, and I've been really sold on its capabilities.  There's some great stuff that it can do.  Based on some comments I've seen, though, I don't think that everyone understands fully what it was intended to be.

The biggest misconception is that WinFS is a filesystem.  It is not.  It is a relational database overlay that works alongside NTFS.  It is also more than just metadata.  Windows XP offers limited metadata capabilities, and it seems that Vista is building on that, even without WinFS.  With powerful search capabilities, including ADO querying, many new uses will come to light.  Not everyone can develop a desktop search engine like Google Desktop or MSN Desktop Search (though the concept is simple enough), but building on top of that index is something being done more and more.  It will only get better with Vista.

Another thing is that the incorporation into SQL Server may not necessarily just be a money grab.  I'd be willing to bet that Microsoft intends to continue the free "Express" versions of both SQL Server and Visual Studio in the next versions.  It would not make sense to pull this non-structured data ability out of the Express edition.  They have too much to gain by its widespread adoption.

So the big question is, what is WinFS, and how much of it will we get.  WinFS was great because it was basically just a very accessible database.  You could drag files into the store and create file-backed items, or create items programmatically with no actual file backing.  Essentially, either one is an Item with the same properties, other than one has an underlying physical file.  So, a JPEG file would have a Photo item associated with it, while a Contact item would only be the item itself -- a collection of properties.

The big deal, is you have Contacts, Messages, Photos, Documents, and anything else at an equal level.  Regardless of underlying files (or not), all items were able to be queried, updated, created and treated as properties.  In a programming environment, each item conveniently becomes an object of a given type.  In your programming model you could deal with this items without ever necessarily dealing with the file.  Let Microsoft Word handle document creation and edits -- your application can build all sorts of meta-functionality based on the structure and content of the file, just the same as with photos and people (contacts).  It's weird, it's somewhat abstract, but once you get your head wrapped around it, it's somewhat revolutionary (somewhat, anyway!).

If WinFS is no longer to be produced as it is now, it's unclear what we will get.  Perhaps the key technology as integrated with SQL Server can be fairly easily integrated with the Windows Search Engine index, but why should this be extra?  I think that part of the problem may have been the complexity at first glance.  WinFS had nothing to do with your physical or even logical disks.  A WinFS "store" existed in its own shell namespace, like Network Neighborhood.  You even used the UNC naming convention (\\machine\share) to access it.  So Joe Average User has C:\, D:\, and \\MyMachine\DefaultStore.  This other "partition" can have files dropped onto it so it looks like another drive, but most people wouldn't see the point.  The thing about WinFS is you only see the value at the application level.  Applications can do amazing things by treating all of this data consistently.  Your mail messages are items now -- no PST file (ideally, anyway).  Any mail application is looking at the same messages.  You would be a fool to create a method of saving email messages in this system.  On the other hand, if you wanted to write a program to provide some unique view of emails -- portal, dashboard, etc. -- you have access to everything without learning the API of the "controlling" application.  Data is free as it should be!

The best thing, in my opinion, would be to truly overly WinFS so it exists atop other partitions.  This is probably not practical due to the enormous number of system files that wouldn't benefit from the arrangement.  Perhaps, instead, I should say the the best scenario would that all user documents would "live" in the hybrid WinFS location.  If all applications wrote only to the WinFS overlay (other than admins), you would have a great system.  It's really only the user-level files that users want to query (well, Joe Average User anyway...).  To enforce this, executable files should be prohibited from launching from this location.  Make sure that users have an easy way to not only install applications, but even to save those little applications (hex editor, file converter, game).  Windows needs to do a better job of enforcing a separation between documents and executables.  WinFS seemed like a start in that direction, but now we'll just have to wait and see.
Comments have been closed on this topic.