Neville Neville

Niner since 2005


  • Shishir Mehrotra - WinFS beta 1 team meeting

    Beer28 wrote:

    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:\
    MSH Contacts:\>get-childitem

    Name Phone
    ------- --------
    Jack 555 1234
    Jill 555 5678

    and in CMD...

    C:\> net use E: \\Computer\DefaultStore\Users\JoeBloggs\Contacts
    C:\> e:
    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.
  • Shishir Mehrotra - WinFS beta 1 team meeting

    Beer28 wrote:

    I believe that the WinFS is virtual filesystem that stores indexing data, and provides SQLD services.

    I may be wrong here, (no doubt someone will correct me if I am) but I believe WinFS is a Virtual Object Store, that provides SQLD and filesystem services.

    The difference?

    • Queries return lists of typed objects (person, video, email), not virtual directory lists
    • The built-in, extended, and added (new software install) data schemas have class reflections that are fully and dynamically integrated into the CLR/CLI of .NET
    • <speculation>The filesystem layer is a legacy layer, future programs will not use WinFS to retrieve a win32 file handle, they will only manipulate the WinFS object (and any underlying data on disk) through one of its exposed interfaces. (stability/performance tradoffs involved in this left to the imagination of the reader)</speculation>

    So in a attributed filesystem like BeFS I can list a directory or run a query and get back a list of files and for each of these files I can then list and retrieve its attributes. One of these will be a type attribute, and from that and documentation I can expect certain other attributes to exist.
    Attributes of course can be indexed.
    Attributes can be added.

    In WinFS on the other hand I can list a store or run a query and get back a heterogenous list of objects. They will all have some common interfaces, but also the interfaces specific to their type, as documented.
    Attributes of the objects can be (are? to what extent?) of course be indexed.
    Interfaces and attributes can be added.

    Which way is better? I don't know.

    Is strong typing in programming languages always better or worse?
    Is a simple class hierarchy (htmlDoc->getElementsByTagName("title")...) or a custom complex one (htmlDoc->html->head->title) better?

    What is clear is that the WinFS approach fits in with the CLR/CLI and the Object Manipulating Shell (MSH/Monad)