Neville, the sql object provider layer is nice, but it's just a layer right?
You could provide the same sql object provider with MySQL and mono or with C++ on linux.
The Win32 file api is just a layer to a binary store (NTFS) too. My point isn't that layers can't be added to interoperate. My point is that MS is developing the WinFX/WinFS api and (I speculate) deprecating the Win32 file api. Are they right to? Will it work? Hell, I don't know. I used to think Hans Reiser was the best bet for improved FS semantics, and MS was spinning its wheels, now I'm not so sure.
The Win32 file api has a fixed schema for the objects its contains: Directory, File, Attributes. Further classification is value dependent, not type dependent.
BeFS was like this too. BDirectory, BFile, and a fixed set of attribute types (int, string, ...)
So to determine further classification BeOS had to provide a FileTypes service that told you that BFiles which had a TYPE attribute with value text/rfc822 had a Sender attribute of type string.
Mac OS seems to be going down the BeFS route (see Ars Technica), but with the UTI improvement.
ReiserFS too to some extent although the FS Plugins and the overall vision adds significantly more to the mix.
The WinFS api on the other hand looks to be designed to have a dynamic and discoverable schema. And the UI (GUI and CLI) will depend on that fact. Type information is provided in the same way as for any CLR object. Objects in the store can be manipulated like any other CLR object.
Beer28 wrote:What interests me most is that it's just a virtual file system that points to data on the ntfs volume. So WinFS, isn't really a FS at all.
I think its fairly clear from the video that there will be some pretty important stuff in WinFS Stores that have no existence outside the database. Like Contact objects.
I can see the following being possible in Monad...
MSH C:\> new-drive -name Contacts -Provider WinFS -root "\\Computer\DefaultStore\Users\JoeBloggs\Contacts"
MSH C:\> set-location Contacts:\
Jack 555 1234
Jill 555 5678
and in CMD...
C:\> net use E: \\Computer\DefaultStore\Users\JoeBloggs\Contacts
E:\> dir /b
but if you tried to find Jack.mscontact on any Hard Disk, the closest you would come is something like C:\Users\JoeBloggs\DefaultStore.sql - The SQL Server Database containing Joe's Default Store.
On the other hand the Word 2000 document \\Computer\DefaultStore\Users\JoeBloggs\All Documents\Report.doc
also exists as C:\Users\JoeBloggs\Documents\Report.doc
But I think Microsoft sees that as the legacy case. They envision user files in the store only, with legacy access through the SMB interface.
Why do it? I might be wrong, but I think if you get rid of the NTFS write through you get rid of File/Save. And a lot of other FS stuff. I think they looked at what was on peoples disks and said, "There are more databases than hierarchies".
I think Hans Reiser is looking to improve the Unix File System while staying true to its "Everything Is A File" philosophy.
In contrast I think the guys developing WinFS are database guys. They didn't drink the EIAF kool aid. They are not building a database add on to NTFS, or an object layer over NTFS, or a search index, or the new improved windows file system. I think they are making an object database the heart of how user data is stored on windows systems. And it works well enough right now to stick up on MSDN.
We are not in Kansas anymore.