We are filling our disks with digital data - photos, documents, slide decks. WinFS makes it easier to find information through rich searches, relate it to other information (e.g. a document to a contact), and act upon it. In Longhorn, all end-user data will reside in WinFS. The data model is built on relational database technology.

Accessing WinFS
From a development standpoint, WinFS is something that you can use to expose properties to; subsequently you can use those properties to increase the power of your applications. If you have an OLE Document or similar store, metadata can be automatically propagated out to WinFS; otherwise you can add your own custom handlers. You can build unique data types in WinFS that can then be accessed via the shell or your own application.

There's a default store installed with Longhorn that you can access with the UNC \\localhost\defaultstore. WinFS supports the same semantics as NTFS - document extensions, namespace resolution and so on. By right-clicking on a file in WinFS, you can edit custom properties. If you have a handler, this will automatically surface the metadata that you have exposed. If you use standard file formats, users will automatically get a user experience improvement.

WinFS Core Concepts
WinFS is handled within the System.Storage and System.Storage.Schemas namespaces. Perhaps the most important class is Item (the new atomic unit of data - the WinFS equivalent of a file). Relationships add power to the model by explicitly relating items together (e.g. an author relates a document to a contact).

Schemas allow for context-sensitive modelling of data. Windows will include schemas for a number of common everyday items (documents, messags, annotations, notes, media, audio, video, images, events, appointments, locations, tasks) and system objects (tasks, configuration, programs, help items, security). These are just the starting point - it's up to developers to further build on this platform.

You can create your own item types by declaring an XML schema extension. For example, a law firm might want to create a schema extension called LegalCase. This contains a number of fields that have SQL types, e.g. ClientNumber -> WinFS.nvarchar(255). Fields can be single- or multi-valued. Once you've created the schemas, you can go ahead and query them from Explorer. Schemas can be versioned to ensure forward and backwards compatibility. There's also SQL-like syntax for querying the store called OPath.

Programming WinFS
WinFS Schemas are converted into partial classes that provide a CLR-based programming model for accessing them. This is the primary mechansim for accessing WinFS - the classes can be created and accessed from VB or C#, and in combination with a number of system helper classes (such as search), can be used to access the file system.

T-SQL is another option for accessing the store - you can use ADO.NET to access the same meta-data, but it is read only. WinFS items can be serialised into XML too. Lastly, WinFS is backwards compatible with Win32.

WinFS Services
Most system files will continue to reside in NTFS, and you can continue to store data in WinFS. However, user data is by default stored in WinFS (the \Documents and Settings folder is moved into WinFS on upgrade). There are import / export utilities to move between the two.

The core of WinFS will support standard operations such as backup / restore, anti-virus, quota and security configuration. As a result of its database heritage, powerful bi-directional replication of items is built in (merge replication, transactional replication etc.) It's possible to extend this too, by building custom conflict resolution handlers and synchronisation adapters.

Finally, WinFS includes a rules-based engine called InfoAgent, which enables the system to be personalised - very like the rules and alerts capabilities in Outlook 2003, or the status information in MSN Messenger. Once again, this is extensible: developers can build custom events, contexts and actions.