Brandon Live!

Sorry Yahoo, your name didn’t fit. 

So I’ve been thinking a lot about Instant Messaging lately.  I think Chris got it right in his post last week.

Since I just wrote a lengthy response over on Scoble’s blog about this… I’m just going to cut and paste it here.  Yeah, I’m lazy… but it’s 9pm and I haven’t left the office yet.  So forgive me.

I think what the IM companies are trying to figure out is… if we don’t tie the client to the service, how does the service make money?

As wonderful as it would be for some graciuos company to “donate” instant messaging servers to the world… I don’t see it happening.

Right now AOL and MSN make money by showing ads in the IM client. If people use different clients, you don’t get paid for the ads. I think Google thought of a different way.

I don’t think Google would have used the Jabber protocol if they didn’t think they could use the Google Talk service (not just the client) as a way to drive revenue.

You see, Google may tout their new IM service as being “open” because they use an open source *protocol* - but it doesn’t address the most significant isssue with IM’ing today… It still has to go through a central server.

The moment you require me to connect to talk.google.com in order to communicate with my Google Talk buddies, that’s when you become a closed system.

I think the solution isn’t to let other clients connect to your server. Nor is it to make people use the same server (ie. the current arrangement) to talk to each other.

I think the solution is to get the servers talking to each other. If I sign in to MSN Messenger, and my buddy signs into Google Talk… we should be able to chat. The MSN server should talk to the Google server and say, “Hey Google, Brandon is online. Are any of his Google contacts online?” And Google should say, “Why yes, Chris and Jon are online”.

Then MSN could say, “Hey Google, tell Jon that Brandon says hello.”

I mean… why not? We do it with e-mail. Why can’t we append a domain to our “Screen Names” and agree on a standard with which to resolve and forward them?

I work for MSN. But I like Google. If I saw MSN and Google agree to work together to accomplish something like this (interoperability between our IM networks), I would be ecstatic. If AOL didn’t want to join, I think they’d suffer. At some point they’d have to. Then we could stop running 2, 3, or 4 IM clients (and by “we” - I mean those of you that haven’t discovered Trillian). Then we could connect to *one* server and be done with it. Then we could actually choose based on the *product* - and not based on what our friends use.

First off, let me say that I am very impressed with the work the WinFS team has done and that they’ve already won a great deal of respect from me.  That said, I’m not 100% sure I see the need for their product.  This opinion is certainly not set in stone, but from what I’ve seen and what I understand so far… I’m not sold.

Why is that?  Well maybe it’s because I watch videos like this one and I think… why is that different from what we already do?  You can tell that these guys are super fired up about the fact that they’ve matched parity with the basic Windows filesystem.  And I’m sure it wasn’t easy, and as a developer I was impressed.  But as a user I thought, “Great.  You have parity with the current system.  Now what are you offering me that makes your effort worth while?”

And that’s where WinFS runs into trouble, in my mind.  I see it as a great technological feat, but one with few or no rewards.  I think Everything I saw so far from a user perspective can be done today, without WinFS.  Some of it hasn’t been done… but it could be.  I sat here watching the video with some other members of my team and several times one of us would say “Looks like our stuff,”  or “Yeah, we could do that.” 

The way I see it, the fundamental difference between WinFS and the Windows Desktop Search “platform” is that they embed the actual file data inside the database.  Whereas, we have a database with all of the item’s data, and then we have a reference or URL to the item (be it a file, an Outlook e-mail or contact, something from Thunderbird, etc). 

The other differences are just implementation details.  They implement their types as CLR-types.  That’s pretty cool, but I don’t see why we couldn’t do that in theory. 

But as a user AND as a developer, I don’t really care where the actual data is stored.  I don’t care if it’s in a file under some folder.  I don’t care if it’s a MAPI item stored in a PST or on a server.  All I care about is that I can query the system for this data regardless of where or what it is, and sort, group, view, or manipulate those results however I choose.

So in the video, they demonstrate an app that displays all your “stuff” on a timeline, and divides it into bands based on tags or properties.  You could do that today using our WDS APIs.  They show creating “relationships“ between a group of photos.  We do that today in Vista beta 1 with tagging.

They show an X1-like app that lets them filter results.  So they do a search for all the meetings he’s had in the last 30 days.  We can do that today.  Then he gets a list of all the attendees from in that list (meetings from the last 30 days).  We can do that (even if it’s not completely exposed in our UI so far) - and Vista does it all over the place.  Then he saves the query.  We can do that today.

Now, the next thing he does is cool, and it’s my favorite part of the demo.  He starts a new query for emails, and filters the From field by the results of that original query (people he’s met with in the last 30 days).  So now he has a list of emails from people he’s met with in the last 30 days, using the saved query from before as a source for the From filter.  Sweet.

But again, I think this is something we could do without WinFS.  In fact, I’ve already started some discussions around here about different ways that we could accomplish these same goals.

The key is that WinFS and our index are both databases.  And we have access to the same metadata that they do.  The only difference I see is that when a program asks us for the result file or item, we give them a pointer to it, instead of actually returning the item directly.  That… and we can index things that aren’t on the local hard drive. 

We can index objects without having to consume them entirely. 

We can go out to the object and say “Give me all the useful information you can about yourself” - and then remember it.  If something changes, it can tell us.  Why would I care if the object actually lives in the database.  Why not let Outlook store data where it wants… in PSTs or on an Exchange server.  With something like WinFS… you’re trying to get Outlook to use the WinFS way of storing items.  And if I want to index e-mail that’s on a server, my guess is that the server has to have its own WinFS implementation for it to federate queries to.  But what if my server doesn’t run WinFS?  Can I plug in a protocol handler and have WinFS pull just the metadata to my local machine?  What if my e-mail server runs Unix and can’t run WinFS?

For all I know, they have good answers to those questions. 

I just haven’t heard them addressed yet.  And it’s not like they’re pressed for time… It sounds like they have plenty of time left to convince me that my all my team’s work is going to be obsolete =)

Earlier than even I expected, WinFS beta 1 has shipped via MSDN.

Tom Rizzo had the original scoop.

There’s a video some demos at Channel 9.

There’s also a new WinFS Blog.

Bazzoni has screenshots!

Just saw that Stephan Schreiber has created an IFS (Installable File System) driver that give Windows support for the Linux “ext2” filesystem.  It’s available at his site, here. 

Like some of the Linux NTFS drivers, this one does not obey the filesystem’s file and directory security.

One must wonder if Windows bootdisks will become a common tool to hack poorly protected Linux passwords

Check it out!

Steve Ickman’s WDS blog