WinFS Mailbox

Hey Everyone. I realized that we needed a good way to reply to some of the comments and questions that we have been getting on the blog and mailed to us, so I’m starting a “WinFS Mailbox” type of post that I’ll do periodically. It’s just like the CBS Mailbag on Letterman, but not funny.

Q: Lloyd writes (I paraphrased and summarized a little on all the mails), “You mention about providing a file store for 3rd party apps. Does this mean that with WinFS I would be able to store my app’s data in a single file with internal database-like access and structure (which I can update with the WinFS API)? For example, I have an app now with its own file format. Can I expose the content of my file to other application through some WinFS magic?”
A: With WinFS you don’t need a separate file. Your data can be described as a WinFS schema and instances of that data stored in WinFS itself. You and other apps can operate on this data using the WinFS APIs. If you need to keep your separate file, you can write a metadata handler to promote and demote metadata between your file and the store. If you would like your file format to be modeled by multiple items (for example, your file is a collection of customer information, where each customer should be an individual item), you would want to write a sync adaptor to keep the data in both the store and the file up to date. We’ll have some posts here soon that provide more details. It’s very cool stuff, but I probably wouldn’t call it "magic". 🙂

Q: Sean asks, “Wouldn't it be great for the WinFS team to host a site where developers could write applications to showcase WinFS, and post them on this site?”
A: You can use for this.

Q: Razielm writes, “Can I get a copy of the posters that were on the Channel9 video?”
A: Unfortunately, the answer is no. Those posters are part of our internal marketing and there aren’t plans to use them in external marketing.

Q: Mikael writes, “How and where are all the relations, keywords, etc. saved?”
A: The item properties are stored in the WinFS store as part of the item itself. WinFS has a concept of “links” which are an entity type with a source item and a target item that relate items. There is also the concept of “common value” relationships which are based on item properties. Navigation of common value relationships is a value based join.

Q: Mikael also asks, “How does WinFS get all the mails? Do I have to copy every mail into the WinFS Store?”
A: WinFS provides synchronization infrastructure that allows you to move information into and out of your WinFS store. Using this framework, developers can build a sync adapter to support synchronization with an external data store. So, for example, you can build a sync adapter to sync directly with a backend mail store, such as POP3 or IMAP4 servers. You can also build a sync adapter to synchronize data on the local machine. For example, an Outlook synchronization adapter can import your PIM data (emails, contacts, appointments) from Outlook. You should check out “StoreSpy” in the unsupported tools folder; this tool includes a one-way Outlook sync adapter. We’ll talk more about WinFS Sync in some upcoming posts.

Q: Mikael also asks, “Do I have to set all relations manually? How does WinFS know which document is created by which user?”
A: The relationship “setting” will depend on how it is modeled. A link will need to be set by something (i.e. metadata handler, sync adapter, application, etc.)  A common value relationship, however, is just based on a join. WinFS depends on the application and user to provide the information to create links. In many cases, an application already has this data; for example, Office applications already have an “Author” property. In other cases, the user already knows this information and can set it. It would be fairly easy to get my primary contacts’ information moved into WinFS and then relate pictures to the contacts. In the future there could be many processes that could be used to relate your data: natural language processing of documents, concept extraction, face recognition for images, etc.

Q: Vince writes: “I'm curious how mail items & such fit into WinFS. Does Beta 1 work with the current (Outlook 2003) version of Outlook or do you need the Office 12 release?”
A: You’ll be able to use a sync adaptor (check out StoreSpy in the unsupported tools folder) to bring items from Outlook 2003. We are still investigating how WinFS and Office will fit together moving forward.

Q: Eirik asks, “I've made a few new schemas for some types, which has Store.Item as a base type. When I explore the WinFS Share all the items I've created with the new schemas has System.Store as types. Is there anything special I have to do to get that right?"
A: For Beta 1, you need to make sure that WinFS can find your schema client assembly by adding it to the GAC. Out of curiosity, what types did you create?

Q: Alex asks, “Will the data be owned by WinFS or can a schema be registered that makes new data available to WinFS, without needing to import a copy of that data into the WinFS database?”
A: The schema definition can exist independently of data; so a particular schema can be installed on a store even if that store does not contain any items of that type.

Q: Kazi writes, “Thanks, very good, and WinFS is really amazing, excellent technology.”
A: Thanks! The whole team appreciates your enthusiasm. 🙂

Author: Vijay Bangaru

Comments (6)
  1. Alex James says:

    Vijay thanks for answering my question. Alhtough perhaps my question wasn’t clear enough. What I am asking is:

    Do you imagine a situation where a schema can be written for WinFS that allows you to use the WinFS API to talk to an existing database (not the WinFS relational store). I.e can we use the WinFS API to talk to data not OWNED by the WinFS relational store?

  2. Massimo Andreasi Bassi says:

    Really good job, WinFS is great and I love the idea behind it.

    I had some problems with StoreSpy, is there something where to post bug reports?

    Anyway, i get the following when trying to sync with outlook:

    "An error occurred with the following information:

    Error accessing Global Address List.

    Stack Trace:

    at Microsoft.Samples.WinFS.OutlookSync.OutlookSyncAdapter.Visit(AddressLists addressLists)

    at Microsoft.Samples.WinFS.OutlookSync.OutlookSyncAdapter.Visit(NameSpace ns)

    at Microsoft.Samples.WinFS.OutlookSync.OutlookSyncAdapter.Visit(Application app)

    at Microsoft.Samples.WinFS.OutlookSync.OutlookSyncAdapter.Receive()

    at Microsoft.Samples.WinFS.OutlookSync.OutlookSyncAdapter.Synchronize()

    at Microsoft.Samples.WinFS.OutlookSync.SyncController.Synchronize()"

  3. Alex DeNeui [MSFT] says:

    Hi Massimo –

    This is a known bug in StoreSpy (we never tested it without a GAL). We will be releasing a new version of StoreSpy that overcomes this shortly.



  4. Quentin says:

    Bugs for any of the WinFS things can be raised on the news-group:

    The domain-specific api’s (like contact, etc.) will only work agains tthe WinFS store. We are working on broader ADO.NET futures that provide more general-purpose ORM functionality. We are talking about this in DAT312 here at the PDC, more on this effort later.

Comments are closed.

Skip to main content