Good afternoon. It's a pleasure to be here again. My agenda today is very, very simple. I'm going to start with the past, move into the present, and then, of course, talk about the future. So let's start with the past, the history, and, of course, I'm going to talk about the history of the Macintosh, and the history started in 1984 with the ad campaign, and that's the software that went along with it, the Macintosh OS, the first version of that OS. Now, I'm not really here to talk about this time, 1984. What I really want to talk to you about is the transitions.

So, the first major transition took place in 1994 when we switched from the original processor of the Macintosh, the 68000 series, to the PowerPC. And that was a hardware transition, of course, but the software was heavily involved in that transition because there was the emulator that was emulating the 68000 instructions, and it was doing that job very well of interpreting the software.

celebrating the instruction of the 68,000 that in fact most of the Macintosh OS still in 96 was still running emulated Which is kind of amazing and it took like two more years to convert most of the u.s To be finally native power PC. So what's the morale of this kind of transition? That was a successful transition But it was very hard the transitions are very hard.

They take a lot of time You know number of years even for a transition with a perfect emulator and you really need to have very strong goals to succeed for your transitions So there's been another transition Of course, I've been heavily involved with and that's the transition from Mac OS 9 and its predecessors to Mac OS X and We had an overriding goal for that transition which was to ally the simplicity of the Macintosh The ease of use the elegance of the Macintosh retain all those great characters that we have But allies that with the power of unix and I don't know if you remember Unix was kind of a bet in those years when we did that Of course unix runs, you know the internet and nowadays it's maybe less of a bet It's more an obvious things.

But back then that was quite a significant bet that we did We had some sub goals if you want to double click to use The kind of Macintosh parlance we had a number of sub goals We wanted to base our stack on open standards open standards means that we didn't want to reinvent the wheel We wanted to add value where we are strong where we have some strong technologies to contribute not reinvent You know some of the basics are likely, you know, the POSIX layer kind of thing We wanted to have a really strong design.

We wanted to have you know layered system with all those layers having a really strong Api's and this is really important because it means that we are bound that our liability is the API It's not the implementation and that means that over the years we can substitute a better implementation to the previous implementation So by us having the strong API's you have a guarantee to always get the best technology over the years We also, of course, had a goal to have the highest performance.

And that, again, was based on having the right structure, having a modern OS, as we used to say many years ago, and having just something that's designed for performance, designed for low latency, things like Core Audio nowadays exploits. We wanted to have great tools, because we believe that in order to really leverage all your frameworks, you need to have great tools and great runtime that goes along. And overall, our maybe overriding goal there was to have a platform for innovation.

So looking at the timeline, I started the timeline in 1998. I could have started it a few decades before with Pink, Taligent, Maxwell, Copeland. There's been a number of names like that. But 1998 was when we had all the elements of Mac OS X, including Carbon. And I know a lot of your applications are Carbon applications. That was a key central element, a part of the Mac OS X concept.

And we were very much at work to make sure that this was actually going to work and to prototype things. And in fact, at WWDC in May of that year, we were able to demo Photoshop with our friends at Adobe. We put together a proof of concept. Then we were back to work. And finally, we shipped 10.2 in 2001.

It wasn't a perfect release, and we knew that. We positioned it. We did it very carefully for early adopters. But it was a necessary release to start the pump of application, to start your applications, because we knew that you couldn't ship until we had this 1.0 label. And quickly, we followed with 10.1. That was filling all the gaps that were in need.

And then we had Jaguars. That was a great success. I'm sure everyone is familiar with the Jaguar logos. That, I think, is in everyone's mind. And we had, beyond the logo, 150 figures. And we had a lot of features in that release. Now, we followed last year, last fall, with Panther.

Again, we added a lot and a lot of features in that release. This has been, as Steve said, the most successful OS release in Apple's history. And a milestone was reached at the beginning of this year when we had over 10 million users. And of course, now we have like 12 million users and 10,000 of your applications.

So the transition is complete. We've transitioned the US over the last few years, thanks to you. That's been quite a transition, quite a lot of hard work. It was a little frightening. I mean, it felt like several years ago that there was this big chasm that we had to cross. And with Jaguar and then PanFar, we crossed it. We went on the side where the sky is bluer. So thank you. Thank you a lot.

We could not have made this transition without the whole ecology moving along. Now, of course, moving along, there's this tiger coming up. And I'd like to do a promise to you, which is we are not going to disrupt the API set for the foreseeable future. That means that we are going to add to the existing APIs.

Now, in contrast, I know there's this other animal that's thinking, "Should I jump maybe halfway across the chasm?" So this was talking about the past. Now let's move on to the present. And as I said, one of our goals is to have a great platform for innovation. Now, platform is really our mission.

All the team at Apple, all the software team, wants to provide you with the best platform. That's what we have in our guts here. Now, innovation is a joint responsibility. It's a responsibility for us to provide great technologies as part of that platform, and a responsibility for you to innovate on top of the platform.

And you have been doing that with Panther. And there's a lot of very innovative apps that have come out of Panther, on top of Panther. And what I'd like to do now is to invite Christine O'Sullivan, who is the senior director for integration, who's going to show some of the most innovative apps you've come up with. Thanks, Bertrand.

Panther shipped 150 breakthrough new features last fall. It has been absolutely fantastic to see the innovation that you, the developers, have built into your application leveraging core Panther technologies. So today I'd like to show you three applications that I think truly shows this type of innovation. So let's get going.

This is an application called NeuroLens. It was developed by Dr. Rick Hoag from Harvard Medical School and Massachusetts General Hospital. This is a brain mapping application. What we have here is a set of MRI scans. And as you can see, as I move the cursor slowly, I can go through slices of the brain and this is very very exciting for researchers as in a single application researchers can display both functional and structural MRI data in a very fast and interactive way.

If I close this window, what you have here is a beautiful 3D view of the structure of the brain. And this really truly shows the power of quartz and OpenGL. What you can see here is a different coloring on the structure of the brain. And actually the author who developed this application, his colleague, participated in taking an MRI scan. And when she was in the MRI machine, she moved her fingers. And what you're seeing here are the parts of the brain that were activated when she did that.

So let me rotate the brain. Again, using the power of quartz, I can decrease the opacity. Isn't that gorgeous? And what you can see here are the brain fibers mapped into the parts of the brain that is really, really important for neurosurgeons as they prepare for brain surgery.

So this is a very simple Cocoa application building on a key core technology shipped with Panther. It's a great app, of course. For those of you that want to try it out, I think you should. And for those of you who are not neuroscientists neurosurgeons, I recommend you don't try this at home.

Let's get going to the next application. Panther shipped professional audio technologies. This is a great application by a developer called Celimony. It's an application called Melodyne. This is a multi-track recording and editing application for music and vocals. What's really, really fantastic about this application is that it enables you to very easily edit pitch, format, and timing information, and edit audio as easy as if it was MIDI data. So let me show you. I have a reggae track here that we prepared.

Now I think even for those of you that do like reggae, that did sound a little off. And as I said, the power of Melodyne enables you to very easily edit audio. So let's go ahead and show you how simple it is. Bring up a new window. Let's resize that.

I can go to the toolbar and choose a tool that enables me to edit pitch. Scale to Snap. And what you're seeing here in the blue rectangles is actually the target regions that the notes should actually be at. So the ease of use of this application simply allows me to select all of the notes and drag them to that target region. So let's try that again. If what you said is what you want.

I actually really don't like reggae music but that's still off. And I think I have the pitch right but I think what's really wrong here is there's an offending note and I think I know which one it is. And again it's as simple as grabbing this note and positioning it, let's say somewhere around here. So let's see if I got this right.

So that's Melodyne. It heavily leverages core audio and audio units, and it's a great application that was just released. So let's go to my third and certainly not last. This is an absolutely beautiful demonstration of integrating many, many, many core Panther technologies into one application. This is Big Bang Chess by Freeverse Software. And this is a game that enables you to either play online opponents or in solo state a chess game. Now what you have here is the integration, as I said, of many technologies. For example, iChat for online play with my buddy list.

Let's go into preferences here. Address book for recording and publishing game and contact information. email for automatically relaying play by email moves. And of course, iTunes for some nice background music as you play. I happen to be a really good chess player. Well, now I've lied in front of 5,000 people.

I'm actually a really bad chess player, so I chose to play a solo game today so that I wouldn't get annihilated on stage. So I'm going to bring up a solo game, and I think I feel like being the sun today. and as you can see that is just absolutely beautiful using the graphics that shipped in Panther. So let's do a few moves here.

I'm getting bored. What you see here is the sun and the moon rotating. What this actually is is a QuickTime movie that's embedded and it's rotating in an OpenGL context. So that's just three great applications that I think definitely showcase innovations and leveraging core technologies that's used with Panther. Of course there are other well-known developers such as Microsoft.

So Microsoft released Office 2004 a few months ago and as is often seen with Office innovation, things come to the Mac first before going to Windows. And of course Adobe and Creative Suite. Well, I was trying to figure what would I say about Creative Suite other than it's creative and it's for creative professionals and I actually want to thank Adobe for being very creative using Panther. Thank you.

You getting tired of me talking? Okay. So I think what we have done and what the Mac OS X team has been tasked to do has been to deliver a platform as Bertrand said for you the developers to innovate. I think you're doing a fantastic job and keep up the great work. Thank you.

Thank you, Christine. So we've moved along quite fast in the agenda. We were talking about the present, but I know a lot of you are here to hear about the future. So let's start now into the future section. And the future is, of course, Tiger. So there's a lot in Tiger.

In fact, I think there's more in Tiger relative to Panther than there was in Panther relative to Jaguar. And I think you'll find that out on your DVD. So I couldn't talk about everything, so I chose six areas to focus on. So let's start with the first one, denoted with this I. Okay.

Now this section is all about data. And what do you think about when you think data? Maybe you are thinking about the character from Star Trek? No, of course not. You think about computer data, you know, all the bits generated by your computers. But there's something that has happened over the last few years, which is quite interesting, is that a lot of the bits are not just generated by computers, they're generated by our devices. In our digital life, we have, you know, the digital hub and all those things that generate a lot of bits. And in our private life, we use a lot of those bits rather than just computer bits, which is kind of a lot more interesting.

We've gone over the last few years from an analog world to a digital world. I mean, I'm sure that everyone here a few years ago was using an analog camera, and now it's digital. Maybe we are at the forefront, but I'm sure pretty much everyone here uses a digital camera. And if you look at music, the icon of the 80s, of course, was a Walkman.

And the modern-day icon is the iPod, of course. And if you look at the documents that you have in your file cabinet at home, there's a lot of papers that you used to have for your tax returns and all those things. And nowadays, they're just PDF documents. So we have really, really started to use this power of this digital world. And we have now a lot of digital assets that are the result of this digital activity.

But we are not fully exploiting all the capabilities of those digital assets. Because for the most part, those documents are what you see is what you get. You know, the picture is what you can see. But there's a lot more that you can do with that picture, because you can attach information about the picture.

The camera, for example, can attach, of course, the date at which the picture was taken, and in a few years, maybe the place at which the picture was taken. And the camera, I hope, one day is going to attach all the parameters of the picture so that you can enhance that picture down the pipe. If you look at your songs, of course, they contain a lot of information about the songs. It's not just what you can hear. And something goes with documents. It can be copyright notice, offer shape, titles, all those things.

All this is metadata. Metadata is information about data. And when you have files-- - Yes. - Yes. - Yes. and you want to inspect the metadata, one thing that you can do is to get info. And that's why I chose the I symbol for this section because this is a fundamental concept, how to access the metadata.

And we actually have a number of applications that enable you to view and edit metadata. iTunes is obviously one. Okay, you have all your list of songs there, and when you select a song, you can ask for all the information about the song, and you get the offer, et cetera. If you download a trailer, same thing. The metadata contains the copyright notice, which typically has the company who made the trailer.

Even if you have Office documents, there's this pane that you may not have seen, which is a properties sheet, where you can actually not just view the metadata, but also edit it. You can add a copyright notice and so on. The problem is that very few of you probably have ever noticed this properties sheet, because it's not that useful to capture all this metadata. The real power of metadata comes in once you can search it. If you can search metadata, then you can have rich queries. You can ask for things like, "What are the images I opened in the last month?" Because a computer knows what are all your recent opens.

And you can ask more complex queries, like, "All my WWC documents, where WWC is a string that can be both either in the metadata or in the contents of the document itself." So the question is, how can we devise such a system that deals with metadata as a first class citizen? So there's one approach. That approach consists in saying, well, let's put everything into a database, a relational database.

And then, of course, we would define the schemas that you have to use, OK, because database need very strict kind of schemas. You probably need to rewrite every application to conform to the schemas, because we've defined the schemas for you. And you must comply, because if you don't comply, we are not going to be able to find your documents. That's what I call the Borg approach.

Now we are not going to do that, I want to reassure you. We have a much softer approach. Our approach is to devise a system service, a system-wide metadata store. This is the heart of the spotlight technologies that were shown this morning. The way it works is that metadata flows into it and of course is used from the store. So let's look at the two sides of that picture.

First getting metadata into the store and that's done with a very straightforward technology that we call the importers. What an importer is, is just a piece of code that runs when a file changes and that given a file is able to extract a dictionary, you know, a list of key value pairs with all the metadata information. And we've enhanced our kernel and file system to have a whole notification infrastructure so that as files get modified, the importer get automatically called and import the metadata.

We will ship with a lot of the standard formats for files. And so if you use in your application one of the common formats, you have nothing to do. It's going to be understood automatically by the system. But it's extensible. So there's a very simple API. It's actually a one-function API that, again, given a file, you must produce the dictionary of the metadata. So that's how you extend if you have a unique format.

Okay, so you got all your data, all your metadata into the metadata store. So now let's say you are an application, say the finder as was shown this morning that does a query. So there's a query that goes to the metadata store. Then there's the results that are going to come asynchronously from the metadata store to the requester application. And you will then display the results. Now the display of the results might be a mix of content information, pure content information, and the results. So you can display your data as well as metadata, some of the columns returned if you want by your query.

So you can have really rich queries. There's a little query interpreter in the metadata store that understands a tree-shaped kind of query. So you can really build complex queries here. But it's super fast. You've seen the speed this morning. This is really, really super fast technology. and it provides for live updates which is the underlying technology for getting to smart folders.

That means that your query keeps there, okay, unless you want to close it, so it's still alive. And as new files get added to the system, the system will automatically notify that there are some new files that matched and then you'll get that added to your results. Standing queries.

So that's the metadata store technology, the spotlight technology. There's two key new APIs for your application to leverage. One is the importer API to define a new importer. And one is a query API, of course, to submit a query and get the results. So just to summarize our approach, the documents continue to be stored in files. This is not like you don't have to restore everything into a relational database or anything like that. We keep the storage the same.

The formats aren't changed. There's no new format added here. It's all those common formats that you find all over the place. We just add a new service, a system service that handles the metadata. Essentially, we boost the file system for metadata. And all new applications continue to run and modify.

When Tiger ships-- if you have a new file-- if you have a file format that's specific to your application for which we didn't provide an importer, you can ship the importer outside your application on top of Tiger. You don't have to even reshape your application. Your application continues to work unmodified. This is very evolutionary as a general philosophy.

Now, there's other technologies as part of Spotlight. I had one of those rich queries, which was find all the WWDC documents. And WWDC could match in the metadata, or it could match in the content of the document. To do that, you need full text indexing. So we've been working hard to really improve our full text indexing technology.

Last year, we introduced Search Kit with a whole bunch of APIs, and we've enhanced that. We've made that a lot faster, up to 20 times when you search, and three times to index. And I think we still have some room to go there to really optimize things. But the key thing is that the full text index is now always up to date.

So you don't have to have the user force an index of everything. It's always ready for you to ask that question. And as you saw again this morning in the demo, it's really fast. And we've mixed the metadata query engine with the full text search so that you can have mixed queries, of course. That's how the Find Me or the WWDC documents works.

So I think we have a lot for you with just those two very simple API additions to really leverage the power of metadata. Now, the key, though, is that you need to really now pay more attention to metadata. So when you have an application that creates new document, you need to make sure you capture all the metadata and you put that in the document along with the document.

That's really critical to make all this kind of really work well for the end user. If you have an application that transforms from one document to another document, you should make sure that you preserve the metadata as you transform. And the good news is that most of the applications out there already do that. That's why the system works so well already.

If you have a new type of document, one that's not common, you can add an importer. And I'm sure that you are going to find very unique ways to leverage all the query API. It really changes the way you program when suddenly you can have a query and very, very quickly get all the results of that query. You do programming in a different way once you have such a functionality in the system.

So that was metadata. Let's move on to another topic. and that's about storing data. For the last few years we've had this request. So when are you guys going to ship a database? Now I just talked about metadata and how we enrich a file system. Do we still need a database? Now that you can have, you know, fancy attributes along with your files? Well the answer is yes because sometimes you have lots of little objects that you want to put in your database. And as we all know the file system has a fairly coarse granularity. Each object is a few kilobytes. And sometimes the things that you want to put in your database are just a few bytes. Databases are very good at doing that kind of stuff.

Now also databases are very good at storing relationships. Entities and relationships, ER diagrams, you know, all these things. I mean there's a reason why this is associated with RDB. The R stands for relational. Databases are very good to maintain the atomicity across relationships, for example. And some of you may want to do SQL. Now, to be fair, there's probably half of you who want to do SQL, and there's probably another half of you who wants to have nothing to do with SQL.

So we wanted to really satisfy your need for a database. So we searched for a database we could add to the system. We wanted to have an embedded database, something that you can embed to your application, link it in, and use that as a library. We wanted the database to do SQL, of course. And we wanted to use an open source database. We didn't want to reinvent the wheel for database.

I mean, there's a number of database that are very popular there. But above all, we wanted something extremely lightweight, because this is for your application to link with it. So we didn't want to have a full heavy duty kind of database. We wanted something that you can embed that's really, really, really lightweight.

So we search for all this. And as we search, we find out that there are several groups within Apple that were already using the same little database. So we said, hey, why don't we bundle that one? Because it seems that independently, many small groups within Apple have met that already, have evaluated, and find out that there's one that's better than the others. So we will ship with Tiger SQLite. That is a very lightweight database that has all the characteristics that we wanted.

So that should really satisfy the half of you who wanted to do SQL queries in your application. But there's the other half of you who wanted to have nothing to do with SQL. You want to hide the SQL generation. And we have something for you. It's called Core Data.

Core Data is an object-oriented framework that's built on top of SQLite and for debug, it's actually, you can also go to a flat XML file. Obviously, you cannot ship that way because an XML file doesn't scale very well, but for debugging your applications, that's fantastic. It leverages Cocoa Bindings, this framework. So, I maybe need to explain Cocoa Bindings.

It's a technology that we introduced last year that enables you to keep the model and the view in sync. So, if you have your model for your data, you have a database or, you know, in-memory kind of store of some kind, and you have your UI, let's say both have fields.

You know, there's a person field here and there's a person field in the UI. What you have to do is maintain those two things in sync so that if the database, the store changes, that value is reflected in the UI. Vice versa, if the user edits the name of the person or something like that, you want that value to be propagated to the database.

The Cocoa bindings enable you to specify that this field in the database is really bound to this field in the UI. And so automatically, it does this binding and it gets rid of all the code to make sure those tools stay in sync. So Core Data leverages that functionality.

We also have some modeling tools to enable you to have some basic database, SQLite database. And all together, it enables you to do rapid application development because you can do significant applications with significant functionality with no code. And I know that's hard to believe, so I'd like to invite at this point Andreas Wendker to demonstrate usage of Core Data. Thank you, Bertrand.

So Core Data makes it really easy for you to manage your application's data objects, both in memory and on disk. And we are going to support three different types of file formats-- SQL databases on top of SQLite, human readable XML files, and binary archive files. What you see here on the screen is actually a typical XML file, as it could be managed by Core Data. And I'm now going to build an application for it.

So I'm going to switch into Xcode. I'm going to start creating a new project. I'm going to choose one of the new project templates, the Core Data Document-Based Application. Just have to enter a name. In just a moment, my project should come up. It really will. There it is.

So as it is common with Cocoa applications, my project comes preconfigured with a document class that I can use for my own customizations. And what's new here is that it has a new superclass, the NS Persistent document, which already knows how to use core data to automatically read and write my data objects to the file system. The project also comes with a new component, the model. The model is a description of my application's data object, and it's needed by Core Data. Instead of entering it here by hand, I'm simply going to import it from the XML file I showed you a moment ago.

So what you see here-- What you see here is an entity relationship diagram of the object stored in the XML file. And we derived it from the structure of the XML. As you can see, we are dealing with persons, locations, events, equipment. So we have a little event management system in front of us. Now I just need to generate the user interface. So I'm going to open the document, document.snip file in Interface Builder. And then I'm simply going to drag over one of the entities from our model into my window.

So this uses Cocoa binding so that I don't have to worry about writing code to populate my user interface. Now let me start building my project. And while it's building, I have to show you one more thing. The project comes pre-configured with three different document types, one for each of the five formats we support, binary, SQL, and XML.

So it's finished building, so let me run my project. Here it is. The first thing I'm going to do is I'm going to open the XML file. Here's the data in the XML file. It even has some pictures in there. I can also enter some new data in the other window. Maybe one more.

I'm now going to save this file. And here it's asking me for what kind of file format I want to use. These are the three different document types that are pre-configured in the project. So I'm going to use SQL this time. Now I have an SQL database on my desktop. So let me close this. Let me open it again. There's my data again. So as you can see, without writing a single line of code, I was able to write a fully functional desktop application. And with that, back to Bertrand.

Thank you, Andreas. So I think we have a rich array of technologies for you to store data. We've the enriched file system with metadata, and now with SQLite, and RAD development with Core Data. Let's move on to another topic. This topic is thinking, thinking data. So maybe I need to motivate that a little. We live nowadays in a very mobile world. People use computers all over the place, even in airplanes to do iChat as we saw.

And we released great new products that really support all this mobility. Now you can be in your hotel room, plug in the base station and you have full freedom of movement. You can be with your portable wherever in that room without being wired. So this is really the hardware side of mobility. But there's also a whole software side to mobility. We've worked really, really hard to make Mac OS X a very mobile platform.

From a software perspective. We work really, really hard each release to make sure you can open that portable and right away be able to use it. We really work hard to make sure you can sleep and wake it up and connect and disconnect from after having mounted file servers. And all those things.

We added VPN in the last release. So there's really a lot of work that goes into making all that really, really smooth. But there's still some work to be done. So if you have a lot of your world on your portable and if you have another computer as many of us do, whether it's at home or at work, you really want to have the same data on both of your computers.

And the problem gets even worse once you start putting some of your addresses on your telephone and here you are, you meet a friend and type in this new address on that little keyboard and now you have this address on your phone. You also have the iPod where you may have things like your calendar information and half a million of our users have a .Mac account with this server in the sky that holds a lot of information. So the key to all this is syncing technology. And we've had a product for the last few years that's called iSync that really does well that job. But what we are doing now is we are taking the engine from iSync. And adding that to the best OS.

We call that sync services. And it can do all the same tricks that iSync used to be able to do in terms of the data types it understands. Your contacts information, your calendar, your bookmarks. And it can do a few more tricks like it will be able to sync your key chains.

So that wherever you go, any website, on any machine, you'll be able to find all your passwords again. It can do mail preferences, mail rules. I'm sure you encounter the program daily when you switch machines. And there's a number of applications that we intend to sync, for which we intend to sync the preferences.

The engine is also revamped in this version too. Rather than having to sync all the devices with all the data types at once, you'll have really fine control over exactly which data type you sync on which device or for which client. It's going to support incremental syncing, optimizing the connection so that you minimize the traffic.

And it has some great facilities to solve conflicts. Now, conflicts is really important in syncing because when you have no conflicts, well, syncing is just copying. That's really easy. The problem, the difficulty of syncing comes with recognizing the conflicts and not having too many conflicts and then having the proper UI to solve conflicts. So all this functionality is going to be available in sync services. But the one thing that I know you've been asking for a while... is to have an SDK for sync services.

So this SDK will enable you to use all the standard data types that Think Services already understands, things like bookmarks. And by the way, this is a very good way to manipulate the bookmarks. As you know, there's no API to Safari to access the bookmarks of Safari, but you'll be able to do that via Think Services.

You can extend the existing data types that are programmed already into Think Services. For example, if you want to add, let's say, a click count to your bookmarks, you'll be able to add that field, and that will be understood by Think Services. And of course, you'll be able to define new data types.

In terms of the clients and the devices, you will be able, using Think Services, to really simplify adding a new device, adding a new client. Because what we brought is the connection, the knowledge of one client of the other clients. So each client is... programmed in its relation of the other clients.

So if you have a new device, you know, some gadget of some kind for which you think a certain data type, you don't need to know about all the other clients for that data type. We've broken that connection. And you'll be able to do machine-to-machine syncing via .Mac for all our users who have a lot of .Mac accounts.

So this brings me to .Mac. It's really, really powerful to have a server in the sky just like what .Mac is. It means wherever you are on the Internet, suddenly you can access your data. Now, I'm pleased to announce that we're making the .Mac API public so that you will be able to enjoy the same level of integration that we've been enjoying at Apple with our applications, the integration between the apps and .Mac.

We believe this is going to enable a totally new category of features. I mean, we don't know exactly what kind of features you're going to come out with this, but we know there's something big there. Because once you have storage, you know, on .Mac, now you can store your own information on behalf of the user. You can add to that storage, and you can republish that information by whatever means you want. So think, for example, if you have, like, a program that generates labels.

Okay, and you have this database of labels. Now you can use that information in .Mac to publish it. Lots and lots of possibilities. The API to .Mac is very, very straightforward. There's no networking involved. It's just a simple connection. And .Mac uses standard protocols and standard ways to access information. For example, the filing protocol is all based on WebDAV. And so it's going to be extremely simple to use.

That's storage in the sky. And because we believe in using our own APIs, that's the way we can convince ourselves that they're good enough for you. .Mac syncing is, of course, going to use the .Mac API. So there's a lot of new possibilities with having a sync engine down into the US. And I'm sure you're going to find really, really new innovative ways to use that in the future.

So let's move on another topic that has nothing to do with data for a change.

So there's a lot of power in the G5. How to get more power? Well, power of two. Put two G5s together. And luckily, all the PowerMax we ship now are dual G5. And the XSERVs that we introduced a few months ago is also dual G5.

And what really is powerful to have two G5 is because we have this technology that's called symmetric multiprocessing. We've had that from day one on Mac OS X. This enables your application if your application is programmed using the standard threads. And there's lots of things that generate threads and that use threads. Some on your behalf and some that you can just program yourself. So if you use several threads, you can essentially have the ability to process.

Things in parallel. Both your G5s are busy at the same time on your application. But for the kernel, we've had to put some locking because there's some system resources that you need to lock. You don't want to have like two kernel threads in the same time in the networking stack or two kernel threads in the same time in the file system.

So what we did in previous releases, we had this big lock at the entrance of the networking stack and at the entrance of the file system. And we've done this for the entire system stack. What we have done for Tiger is break down that lock into smaller locks that have a much finer granularity.

This sounds really easy to do with such a picture, but this picture simplifies reality quite a bit. Now, what this enables you, of course, is to have much more improved parallelism, much greater throughput, both with the file system and networking, in the right condition, when you have a dual processor and when you load those things.

We also used that opportunity to do something that we wanted to do for a very long time. We've had an IOCit that has a stable API, so all the drivers, the IOCit drivers, continue to work from one release to the next because we have an API. We did not have that for file system and networking kernel extensions. And we did not have that because the data structures, the structs, records of the kernel were wide open. And so if you were programming a kernel extension, you were of course using that struct.

And therefore, as we were changing the struct, this would break from release to release. So because we were changing the structs, because we had to put the locks somewhere, so we took that opportunity to also provide an API. So that means that from now on, we can have stable kernel interfaces. Beyond IOCit for file system and networking.

Two G5s, that's pretty good power, isn't it? How about more power? Let's talk about power of 10. Let's just take a rack full of G5s. And of course what this rack runs is Mac OS X Server. So let me go over the strategy for the server very quickly. There's kind of three fundamentals for the server.

The server is Unix based, just like the client, but that's a place where it's definitely even more important. We build on open source. In fact, the server is really taking all those open source services and making them easy to use. And that brings me to the third point, the ease of use and the integration. So let's go a little deeper on that.

Unix. Unix has been a bet for Mac OS X, and this was the right bet. Unix is a power. Unix is the base on which we build both client and server, and it's really robust. That's why Mac OS X is so resilient. It's a Unix infrastructure. Unix powers the internet. Over 3/4 of all the servers on the internet are powered by one Unix and other. That's amazing when you consider the geopolitics of the computing world.

and Unix is an industry standard, of course. And because it is an industry standard, it has created this whole open source movement. And there's lots and lots of open source services that are out there. So what we do is we pick what we think are the best ones, and we bundle them. We integrate them. In fact, in Tiger, on the server version of Tiger, we will ship more than 100 open source projects.

And that's the third point. What we do with the services is we make them really easy to use. We create a consistent and approachable UI to really make like memortals, people like teachers, manage Mac OS X server boxes. And we also integrate the services together. We tweak them as necessary so that they really interplay something that is not done by the open source world. And we also test them working together. That's another thing that nobody does. as in the open source world.

So lots of features on the Tiger server. I'm not going to go through all of them. There's a lot more than this list here. Just a few I wanted to mention. Access control list, heavily requested. Syncing, so that if you have an education setting with some students who have an iBook, you can connect and sync your network home. A number of servers, weblog servers, that will complement very well the personal clipping service, Safari RSS, that was introduced this morning. An iChat server, so that you can within the company, iChat.

As you can see, there's a lot of complementarity between the client and the server. That's another thing that we do. And we make it easy to switch to Mac OS X server with an assistant so that you can easily connect if you have a small business to the internet because it's fairly complex to do those things. There's a number of things that you need to do and the assistant makes all that really smooth. And some migration tools if you come from another OS.

So one rack is a lot of power. How to get more power? Well, why don't you roll in another rack? And maybe another rack. Money is no issue, right? But if money is an issue, why don't you use instead the power of the grid? Why don't you turn a whole network of idle iMacs into a giant supercomputer? Something that's virtually hundreds of gigahertz. And now you can do like factorize prime numbers or whatever scientific computation you have on top of this network, the X Grid enabled network.

So X Grid is this product we introduced a few months ago. We had a pre-release, a technical preview, I believe, in January. And what this does is that it can exploit idle machines. And it's very easy to submit a new task to the grid and to contribute your own machine to the grid as well.

So there's a lot of power coming up with Tiger. If you have a large data set, use 64-bit. Recompile your Unix application for 64-bit. If you have something that has large parallelism, use a grid. If you are developing a kernel extension that's a file system or networking kernel extension, now you have an API to do that, a stable KPI, Kernel Programming Interface. But the best thing of all is that if you develop an application that's outside this domain, that's a standard application, document-centric application-- I know there's a large set of you who do that-- you have nothing to do. All this power is for free.

In CF Network, we are constantly adding support for new protocols. We add support for new proxy servers, new authentication protocols, and we always try to be down to the metal in terms of performance. Always try to strive for the topmost performance with CF Network. But the bulk of our work is in WebKit.

We are doing a number of things in the WebKit area. We're making it easy to access the DOM, the Document Object Model. We are making it easy to write plugins, plugins APIs. All these things have been seriously revamped. But there's one feature that I want to outline. It used to be that WebKit was rendering HTML. What it does now? It's editing HTML.

What I'd like to do is to re-invite back Christine to do a very quick demo of HTML editing. Thanks Bertrand. So for Tiger we want to make HTML editing very simple, but we also want to provide some power to enable you to edit complex web pages very easily as well. So let's go ahead and launch an application that we We wrote using the new WebKit HTML APIs. So let's type in some text. So let's see. Christine, you need a raise. Bertrand. Okay, so there's just some random text.

Let me bold that in case I forget and let me save that. So I'll save it to my desktop. And I'll save it as urgent. And now what I have is, let me drag. This is an HTML document. You can also see that there's a word here called race and it is bolded because it's surrounded by the B tag. So our application created HTML from the text that I typed from that document. So now I mentioned that we also want to make it easy to edit.

I'm going to go back here to edit complex web pages. So this is a web page that you're all familiar with, yahoo.com. And I would like to-- an insertion point here-- and just start changing. and as you can see, I have live resizing, updating as I'm typing in my modifications. This has all been made possible with the new WebKit HTML APIs that we're shipping with Tiger. Thanks.

So we really, really want you to embed Safari functionality into your application. You have access to the core functionality of Safari. You can go to any of the layers and you can use whatever APIs you want there, especially WebKit. And if you do so, you will leverage all the investments that we are making in those technologies.

We continue to push forward as much as we can there. And it's not just us. It's also the open source world because we are exchanging all those improvements with the open source world, the portion of WebKit that's open source. And last but not least, the HTML editing that I'm sure many of you think already of leveraging in your application.

Oh, there's one more thing about web development. This morning you saw Dashboard, the introduction of Dashboard, and Dashboard is instant access to all your widgets. Now, what's a widget? Well, a widget is actually a piece of HTML and JavaScript packaged all together. In fact, the development environment for widgets is Safari itself. That's how you can test that your widget runs.

Not quite, though, because there are some limitations in HTML. If you just limit yourself to the regular HTML and regular JavaScript, you will actually not have the fancy graphics of the hands of a clock, because that's really hard. I mean, I guess you could do it by kind of moving images, having a fixed set of images, but what you really want is the full power of quarts there.

So to address those limitations, we've added two things, and just two. We added a tag, a property on the image tag that enables you to do compositing, and we added a new class, a new JavaScript class that we call a canvas that enables you to render using quarts. And with those two things, the class... can get its hands.

So we really want you to develop dashboard widgets. We want you to prototype them in Safari, to use HTML, CSS, cascading style sheets, JavaScript, and our two small extensions. You can do native plugins. So you can really tap into the APIs of the system, like the address API, things like that. And it's really easy to develop a widget.

In fact, it's so easy that we thought we could have a little bit of fun here. I know that many of you will have come from all over the world, like Peru and a few other countries like that, 44 countries. And you'll go to your hotel room tonight, and you'll turn on the TV and watch TV.

Well, what if instead of watching TV, you were to develop a widget? So I'm introducing the WWDC 2004 Dashboard Widget Contest to encourage the creation of the best innovative widgets. This is how it's going to work. It starts now, and the deadline is Thursday. So we believe it's really easy to develop a widget, and that's why we believe we can do that.

and there's some training starting tomorrow. There's also an SDK that you have on your DVDs that contains information on how to write widgets. And there's more details on the web. Now to motivate that a little bit, there's even some prizes. 15 inch power boot and for the runner-up an iPod. So this should be fun.

So let me now go to the last topic. And it's connected to dashboard because there's fancy graphics in dashboard. And that's quarts. That's graphics. And who's best to talk about graphics than Peter Graffagnino, who has been providing the vision for graphics over the last few years? Thanks, Bertrand.

Hi, everybody. I wanted to spend a few minutes today to talk about some kind of high-level industry trends that we see going on in the graphics stack. There are going to be a lot of sessions on the details and the low-level APIs we're providing. But can I get the slides back, please? Thanks. But let's go through a few things we have here.

I think I might need the other remote. Oh, there we go. Graphics processing power, as you may have heard in the keynote, has really been exceeding at a rate greater than Moore's Law. I mean, it's really been quite incredible, all the parallelism and the capabilities of the chips.

The other thing that's kind of interesting that's also going along at the same time is that these graphics processors are moving from being sort of special purpose game engines to more general purpose programmable engines. So at the same time they're making all those performance gains, they're also becoming more general purpose. And in fact, there's a whole kind of culture of folks who are doing general purpose computing on graphics processors now. Here's a website called GPGPU where you can learn about doing.

Services and modeling computational geometry, all kinds of things on the graphics processor. Now, one of the things you might wonder is how can the graphics? How can the graphics processors be able to continue at this rate? What do they know that the CPU designers don't? Well, the issue is really that their problem is much more parallel and to quote one of the scientists at Nvidia, David Kirk, graphics computation is sort of embarrassingly parallel.

There's just so much data to work through. That you can. Do lots of things at the same time. For example, within a pixel you might have RGBA components. So you've got already four components of parallelism. So that's just a floating point for vector, just like a velocity engine.

Now, what you can do since you're processing multiple pixels at once, you're usually not just drawing one pixel, you're usually drawing a whole bunch. The graphics processors actually process more than one pixel at once. So for example, if you have eight pixels getting processed at once, each one with four vectors, you've basically got 32 floating point operations happening per clock. And it gets even wilder than that.

is in the current generations of chips like the ones announced this morning and in recent months, the processor is actually able to do 128 floating point operations per clock. There's basically a dual issue 16 wide four vector floating point operation happening in parallel. And because there's all this parallelism, one of the things that's really important is to look at new approaches to computing because the evaluation substrate is radically changing. We've got these highly parallel graphics processors and we've got AlteVac, SMP CPUs and a lot of data parallel architectures coming along.

So one of the things we wanted to do with Tiger is try to tame this complexity for you and that's where we get to core imaging. Core image, and here's a picture of the documentation which we got ready for you today. It's a preliminary version, but it's a great reference if you want to get started.

Core Image is a GPU-aware image processing library, but it can also process on the CPU. It's a floating point data precision, as you heard this morning. The plug-ins-- we have plug-in architecture called image units. And the parallelism in these algorithms is what we call implicit. In other words, there's not loops and threads. It's a stream computation model. And let me give you some details on that so you understand.

So another important thing about core image is deferred evaluation. So what happens in this part of the stream computing model in core imaging is an input image gets passed through processing kernels, and no work actually happens until at the end of the pipeline when the final output image is rendered.

What this allows us to do is do what we call computational conspiracy. So you can imagine two subsystems in the OS, like a video decompression subsystem, needs to do a color matrix correction to get the NTSC decoding or whatever correct. So it gets the source video frame and puts on a color matrix computation, and then passes that image along down the chain to, say, a display subsystem. Now no computation has occurred yet. We've just sort of annotated that image and promised that, oh yeah, we're going to add a color matrix to it.

And then later on, the video decode system can get that image and say, well, I don't know what's in here now, but I know it needs to be gamma corrected, and slap a gamma correct kernel on there. And then when finally the frame gets rendered, what happens is the evaluation system looks at all of these things, and in simple cases like this, will just render one quad with the result of the image. So this allows us to have a really modular architecture, and not everyone's looping over the pixels and doing their own thing.

We can evaluate it all at once. So that's a little bit about core image. I thought I would just spend some time kind of motivating the architecture in general. I think we're starting to run a little late, so I'm going to point you at our session later on. But I'm going to go ahead and do that this afternoon, where you can hear more details in a second. But let me do a quick demo.

So we have a tool called Quartz Composer, which we're shipping in a developer DVD. which I heard someone installing as I was waiting to come up here, so I know you guys have a disk. Let me show you real quick where the examples are. If you go on the desktop, two developer examples you will find towards the bottom Quartz Composer.

And I'll show you a few things with Quartz Composer. Quartz Composer is a tool-- you'll hear a lot more about it in other sessions and later on today in Tim Schaaf's talk-- that lets you bring together the power of Core Image, Core Video, and OpenGL and all of the various technologies we have. So let me show a few things first.

This is the composition. It's a data flow model. You've got all the core image units as well as a bunch of controllers like low frequency oscillators. And you can kind of, it's almost a rad tool for doing visual stuff. It's really fun to play with. And this is one of the examples we have that tells you about Quartz Composer.

Every tool has to be able to tell you about itself, otherwise it's not a good tool. And the background is getting blurred with core image and then there's a cube. I can show you the composition a little bit here. You can see the four bitmaps coming in into the faces of the cube and those were just transparently being rotated. Let me show one other demo real quick.

This is a prototype of kind of a wedding scene like you might see in an iDVD title. We've got some video coming through on a texture using this component here, which is basically creating texture using core video, passing it into a background patch, which I can go inside of, and you can see it's doing various things. I get tool tips and I can see what's happening at the various stages. This is actually making a mask out of the image. And this example is not on the DVD, but there's a bunch there you can look at.

Let me show you one other fun one. It's an Apple RSS news feed. Actually, we have an RSS parser component, which can read from a URL. It's going to read from Apple Hot News and create some text, and the text is going to go downstream and get put onto bitmaps and textured, and you'll see what we have with the... With that, this is actually the RSS feed from apple.com, which is kind of cool. And there's also a screensaver you can go look at inside the DVD, which does it like this.

and I'll try to get you guys to your next session. Quartz Composer. So we have a lot of ways to attack GPU computing in Tiger. We're going to be a lot of sessions at the conference. Hear them all come to our lab. And most importantly, come to Tim's talk at 5 o'clock to hear about how we're layering all of the-- both core audio, core video, core image, core graphics, OpenGL, QuickTime, everything all together in some really cool stuff. So anyway, that's all I had. Let me just remind you to join the GPU computing revolution and take all the great tools we have in Tiger and build the next killer app. Thanks a lot. Thanks, Peter.

So we've covered six of the major areas of TIGER, but of course there's a lot more. I, for example, did not mention development tools, and we have a lot of really interesting stuff in the tools, but I want to leave that to the next session, that's just in a few minutes.

And I did not go over the usual, okay, let's talk about Carbon and let's talk about Cocoa and all the other frameworks. Now, we are continuing to invest heavily in those frameworks, but there's about like 200 sessions that talk about all those things, so I wanted to leave something for those sessions.

Altogether, we have a great platform for innovation, and we really hope that you are going to develop great innovation on top of the platforms that we provide. I want to remind you that we've been through an operating system transition over the last few years, a successful transition, that's the animals on that side. And I'm going to end with a few words.

Thank you. Thank you. Thank you. Thank you. Thank you. Also, I hope that you are enjoying the DVD. I saw a number of you already installed the DVD. It is pre-release software but I've been running it and I think it runs pretty great. There's still a lot of time before it's shipping because this time the development cycle is a little longer.

We will ship next year so we are a little not as advanced in the development cycle. However, I still believe it's a great DVD and it's a great release. We worked really hard for you to get it in your hands today. And I think overall, Tiger promises to be a great release. Thank you.