I need to clear up a misconception about WinFS: it isn't a system for storing metadata associated with files.
WinFS is an item store. Items have a type which defines the properties that make up that item. Item types are arranged in a type hierarchy, rooted with a base Item type. For example, here is the WinFS schema for a Foo item type:
<Schema Name="FooSchema" xmlns="http://schemas.microsoft.com/winfs/2002/11/18/schema">
<ItemType Name="Foo" BaseType="System.Storage.Item">
<Property Name="Bar" Type="System.Storage.WinSFTypes.Int32"/>
If I run this schema through our API generator and install the schema in WinFS (neither of which are possible with the PDC release, sorry), I can write the following code to create a Foo item in the store:
ItemContext ic = ItemContext.Open();
Foo foo = new Foo();
foo.Bar = 42;
Folder folder = Folder.GetRootFolder( ic );
folder.OutFolderMemberRelationships.AddMember( foo );
I can find a Foo item using this code:
ItemContext ic = ItemContext.Open();
Foo foo = Foo.FindOne( ic, "Bar = 42" );
At no time was a file created in order to store my Foo item. The best conceptual analogy (and more or less the technical truth) is that a row was inserted into a database.
Now, it so happens that we are using this item store to store meta-data associated with a file. We do this as follows:
1) A file system redirector is part of WinFS. That is the thing that handles UNC paths like \\localhost\DefaultStore (if you are on a Longhorn box, you should be able to click on this link to open your WinFS store).
2) When a file is created through this redirector, WinFS creates an item that represents that file. This item and the file are tightly bound. When the file is deleted, the item is deleted.
3) WinFS looks up a registered file property handler using the file's extension. The handler knows what type of item to create and how to move meta-data between the file content and the item (in the PDC release, this happens only in one direction: from the file to the item. This will work in both directions before WinFS is finished).
In WinFS lingo, such an item is called a file backed item. It is distinct from the Foo item I created in the example above which we call a native item. Many of the types in the WinFS schemas we intend to ship with Windows are likely to be used for file backed items most of the time. For example, Document, Track, and Image. Other types will rarely be used for file backed items. Person, Organization, and Group come to mind.
Note: I decided to change the schema and code examples in this post to a version that is a little newer then that that shipped with the PDC release. We are making changes for good reason... like the new stuff makes more sense and is easier to explain.
asks some questions about how well will WinFS handle very large amounts of data
. Basically the thing to keep in mind is that WinFS is, at its heart, a relational database. There are very
built on the same technology. I would expect WinFS to ultimately have roughly
the same capabilities. However, I can't say (because we don't yet know) exactly how much of this will be achieved in the Longhorn release.
I just hollered down to my daughter that it was time to stop playing with the computer and come up for bed. I need someone to do that for me most nights....
I'm going to jump on the bandwagon...
I wrote my first program on paper by following some snippets of basic code I found in a sidebar of my math text book. I remember writing multi-page basic programs on paper long before I actually had a computer I could use to run them.
I first got paid to write code for an Ohio Scientific Challenger III. I developed some multi-level sales tracking software for a short lived company. I thought I had invented hierarchal storage structures and recursion (then I took CS101 in school).
Other early jobs were done on a Lanier something or another, a Kaypro II, and, of course, an original IBM PC.
I hacked CP/M on the Kaypro to make a disk driver that talked out the serial port to an app running on an HP3000 that maintained a file that was formatted like a big floppy disk. We actually supported multiple users simultaneously. Teachers used this to distribute assignments and collect homework. We also redirected the parallel port for printing.
On the PC, we wrote a TSR that did the disk/printer redirection as well. We also added a feature that let the school distribute (on floppy disks) more copies of software to students then they actually owned. We took 15 bytes of code out of the startup sequence of each app and stored it in a database on the HP3000. We replaced the 15 bytes with a call to our TSR that would check the number of people currently running the program and provide the missing code if all was OK. We even had an offline mode. Some PCs had ROM chips that we could pull the code from in case the HP wasn't available. Funny how I still remember it was exactly 15 bytes.
BTW: http://www.obsoletecomputermuseum.org/ has an RSS feed.