Compartilhar via

Another interesting WinFS scenario

  • Artigo

Jeremy Mazner has posted a few interesting WinFS scenarios. I thought I'd add one that's fresh in my mind.

One of the exciting new features of Mac Office 2004 is simple project management. Project management is an overloaded term, so let me take a moment to explain. Office lets you assign contacts, messages, tasks, events, notes, scrapbook items, and files to projects. There is a rich set of views that lets you manage all of the information in projects. It's a great way to manage your data because you can see everything related to a project in a consolidated view without having to see stuff you don't care about. You can also share projects through a simple mechanism. To share, each user basically syncs to a representation of the project sitting somewhere on a server.

Within Entourage's database, this is pretty easy to represent. We just tag each item with the projects they belong to and can do quick indexed searches for all of the items in a project. Then, we built the rich UI and sharing on top of that. This let us support everything mentioned above, except files.

Files were a different story. Since there's no easy way to attach metadata to files [1], how do you associate files with projects? [2] Even if you tagged them somehow, there'd be no quick way to search across all of your files for files with the tag. You could try to keep track of the files and watch for things to happen to them, but this wouldn't work for many reasons, especially without somehow patching the OS. The solution is to use a folder for each project. Inside this folder, you can put the files associated with the projects. The next question was, when adding a file to a project, do you move the file in, copy the file in, or just copy in an alias to the file? Each has its drawbacks. If you move the files in, then adding a file to a project is somewhat destructive, and you can't add read-only files. If you copy them in, then the user might not understand that if they have two copies of the file now, and if they edit the original, you haven't edited the one in the project (and vice-versa). It also doubles the space required which sucks if you are dealing with large media. If you add aliases, then you risk the danger of a user deleting a file, not realizing it is part of the project, or moving the file in such a way that the alias can't track it. There's also no easy way for users to add things that are stored in other databases like data from Mail.app, iPhoto (I know these are files, but they are hidden), Apple’s address book, etc.

On Longhorn, WinFS solves these problems. There are a few ways this could be implemented. One would be to put all of the items in the project into a list, with holding relationships to all of the items in the list. This would allow you to quickly enumerate all of the items in the list. The holding relationships also solve the ownership issue because they have a ref-counting type model. The item will continue to exist as long as anyone’s got a holding relationship to it. And, this will work with any type of item from any application built on top of WinFS. The sharing side of things could also potentially be built on top of WinFS sync.

I only wish we'd had WinFS when building Office 2004!

[1] Hey, we could just put the project name in the filename! (Inside joke for Mac users who went through religious wars about HFS-style type/creator vs. extensions when Mac OS X came out)

[2] This is also a reason we couldn't move to directly building on top of the Mac OS Address Book. I can write more on that if there's interest.

Comments

  • Anonymous
    March 14, 2004
    Please, write more about why you couldn't move to directly building on top of the Mac OS Address Book.

    Nice article, by the way.
  • Anonymous
    March 14, 2004
    yes , please write about this as it would be really nice if this could sync better particularly the bluetooth integration features as i'd like to be able to use them from Entourage . I have switched to address book for keeping up with my mates because of this as it work so well with my Sony Ericsson . Also , where's the iSnyc conduit ? surely it'd be much easier for you to just write one as opposed to having a palm conduit and then no phone sync support / iPod syncing etc ?
  • Anonymous
    March 14, 2004
    PLEASE PLEASE info on address book and lack of iSync support! :-(
  • Anonymous
    March 15, 2004
    Ok, I'll definitely write on this. A quick note on iSync though. Apple currently does not publically provide any way for third parties to write adaptors/conduits for iSync. I agree that iSync integration would be awesome, if only it were possible. I'll write more on this in the coming days.
  • Anonymous
    March 17, 2004
    Well, you can add your own properties to the address book. There is an "addProperty" method call.

    Though, yes, iSync APIs would really be nice, but it doesn't take long to write sync functionality.
  • Anonymous
    March 22, 2004
    The comment has been removed
  • Anonymous
    March 22, 2004
    With regards to publicly available iSync APIs -- I've heard that they'll be published around the WWDC timeframe. Sorry, have to post anonymously as my source is somewhat privileged ...

    Plus I challenge the assertion that "... it doesn't take long to write sync functionality."