What about the Longhorn server? Can developers begin to build systems without the server version of Longhorn?
The server and the client have not been on the same schedule; as we get further into Longhorn, we will further clarify some of the schedule things. Today was not about schedule. We talked about having the beta (of the Longhorn client) next year, and we gave people the developer preview bits. But we are very clear that this is a technology-driven release that will take quite some time to get in full shape.
All of those schedule things will become clearer -- the notion of what intermediate releases there are for the server. And there are a few things we need to improve between now and then. We have talked about one, which is a security-focused release of the server, and we have even talked about some of the capabilities. We will get all of those intermediate milestones, then explain how the Longhorn server is the culmination of all of those things.
And developers can begin to build programs without the server version of Longhorn?
That's right. There are benefits when you get WinFS on the server or Indigo on the server. But we're full speed ahead on developing Longhorn apps, and some of the people at this conference will begin developing apps right away.
We've been hearing about the WinFS unified storage idea since back in the Cairo days. Why now for WinFS? What has changed?
I'm the biggest believer in this. It took a while for the database technologies to mature to be able to deal with heterogeneous data. That's really the XML revolution into the database. There is no coincidence that, as we are developing this Yukon version of SQL Server, we thought, "Wow, we can take some of that and have it be in the file system." It's probably due to the power of the machines, the amount of information people have. The world of your address book is different from the world of your songs, which is different from the world of your files, which is different from the world of your email.
The number of commands that you are learning -- the number of interfaces -- is very large. People notice that if we put features into one, like the ability to be notified of something new, then they want that capability. They want to know about new music or new family photos or new address changes. You end up, for every new capability, building in the separate silos. People want notification, and they want control, and they want security and replication and rich search. They want a lot in these individual silos.
Now we're saying, "OK, you can get it in one place." Partly, it's the hardware evolution; partly, it's the database evolution; and it's partly that the benefits to users to pulling these things together is critical, because we've really got as many concepts as people can learn, yet they are not really adept at each of those silos because there isn't the sharing that WinFS will bring.
It sounds as though Longhorn helps to revive some of the earlier .Net My Services ideas about personal information management and seamless computing. Is that true?
From the idea that we are schematising personal information, yes. But this is under the control of the user, stored on your client. That's the big difference. With HailStorm (the code name for the scuttled .Net My Services project), we didn't really have the rich query capability to navigate these things. We didn't have content indexing and all of that.
We had the idea of replication, but because we didn't have a (concurrent) OS change, it was very server-based replication. Of all the initiatives we have taken in the last decade, I would say that HailStorm was the one that hit a dead end in terms of how people responded to the information being on the server and the fact that we didn't have rich search capabilities.
Some of the concepts about how people manage their information are revived, correct?
Sure. I think the idea that your address book should be usable by other applications, that your calendar should be accessible by other applications -- that is a big part of Longhorn, because we move those rich user schemas down into the platform so that applications can all get at presence and phone numbers and annotate the address book, instead of things like each application having its own address book.
Some reporters and analysts have pitted Microsoft against IBM over the future of Internet computing. The two companies have cooperated on Web services and other areas. Are your visions that dissimilar?
There is enough in common that I could talk for a long time. And then, depending on who at Microsoft or IBM you talk to, they might choose to emphasise the parts that are different. We're a software company, and we believe that the magic of software leads to reduced complexity and new development platforms and helping security issues. They do software, of course. Most large accounts have .Net and WebSphere in them.
I think that IBM has been our primary competitor in key areas for a long, long time. What's important for the industry is that we have a common vision around Web services. (IBM software executive) Steve Mills and I demonstrated that about a month ago in New York. That is the infrastructure that allows e-commerce to happen and allows software anywhere on the Internet to talk to software independent of computer language, operating system or hardware.
IBM and Microsoft put their best people on this, and it's a real contribution to the industry. It's something people dreamed about for decades. We have been very clear about the road map and getting those standards to workshops. So that is common work. IBM still has its profit stream from mainframes and large systems.
That's very different from us. We believe that software can reduce hardware costs and development costs. And because of that, we focus on what we can contribute to software. So you will see lots of things for which we will compete, and that is very healthy for customers. But we have this common vision of Web services behind it.
