CLI201: WinFS Overview

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.