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.