Well, welcome. Hope you had a good lunch. This session is really critical for anybody who's thinking of embedding Safari technology within your own application or leveraging any aspect of Safari technology, whether you're using Apple Help or these other things, just understanding what's going on with the Safari technologies. And to talk you through this stuff, I want to introduce Don Melton, Manager of Internet Technologies at Apple. Don?

Thanks John. Hi there. Wasn't that a marvelous lunch? Still feeling that. Okay, like John said, this is the Safari overview and I'm Don Melton, the Internet technologies manager. And what we're going to do today, if I can get the clicker to work, is we're going to get a high-level overview of Safari technology and we're going to have a roadmap which hopefully John will remember to read at the end of the session on other useful sessions here at the conference concerning Safari.

I think this is going to be especially useful to those of you developing applications, Internet tools, web content, Apple help content and open source. It's also going to probably be fun for those of you who might have ever used a web browser. How many of you have ever used a web browser? Okay, it's my kind of crowd then. All right. Okay, here's what we'll cover today.

Like John said, Safari technology you can use in your software. We're going to see some demos, and I'm going to talk a little bit about the APIs, but remember this is high level. We're not going to see that much code. And because I'm the manager of Internet Technologies, I'm going to remind you about other Internet Technologies that we have available at Apple, besides just the cool Safari stuff.

So let's get started talking about Safari, everybody's favorite web browser. So Apple released the first public beta of Safari on January 7th at Macworld San Francisco here at Moscone. And I knew it was going to be popular because people were trying to download it from the show floor. People were going crazy over this thing.

And I think within four days we set some kind of record for downloads at Apple. It was pretty big. And then a few months later we released public beta 2 with even more features. And the download rush started all over again. And now this week, as you know, we've released 1.0. This is the GM. This is the real thing. It's not a dot next to it. And the folks at the home office in Cupertino tell me the servers are pretty busy.

So why is Safari such a phenomenal success? I mean, because people are not just downloading it, they're actually using it. And some people are already, even in beta 1, making it their default web browser. I can think of three reasons: innovative features, solid quality, and impressive performance. Let's talk about the features.

Safari is a full-featured web browser. It's grown up even for a 1.0 release. This is just a partial list of some of the features with things like Snapback, integrated Google Search, and what I think is the best bookmarks organizer in any web browser. It's very, very compelling to users. Plus for all us geeks, we've got tab browsing. Who liked that when we added that in beta 2?

Okay. And now bookmark synchronization with iSync. Very, very popular. But the other reason is solid quality. Safari just works right. It works the way you expect it to. It renders web pages the way they were meant to be rendered. It renders them the way the web designer intended them to be rendered, especially if that web designer used current web standards.

But, hey, Safari works even if they didn't. The other reason is stability. I don't know how many times after the first beta came out I heard, "This is just a beta? You should just stick the 1.0 on that. Ship that thing." Thanks. We really appreciate that. We're glad the crashes were few and far between. We'd like to say now, "That was intentional."

We like to think we engineered that quality. So quality is a big draw, and I think this is the other reason a lot of people are already making it their default web browser, even back in the beta. But the most important reason, I think, for Safari's success is the impressive performance. I mean, it's just the fastest browser on Mac OS X.

Not only does it beat the competition in the standard benchmarks, but just in everyday usage, loading web pages, launch time, scrolling and resizing windows. Did you notice that 1.0 is actually even faster on launch time than the previous betas? Worked on that one. It also has a small memory footprint for those memory-challenged configurations out there.

So the question that I hear most often, even around the office, is how do we make Safari so fast? And it's actually fairly straightforward. For one thing, broken clicker, we made performance the priority, the number one priority. We made it a feature. We made it so that engineers and managers would have their own job performance measured on Safari's performance. I mean, we made sure that everybody realized this is job one.

You have to take it seriously. The other thing is we started with great technology, not only Mac OS X as a platform, but also our great open source engine that I'll be talking more about later. My Safari engineering team would like me to mention that we also started with great engineers.

Okay, now what I think is really important here is we took regular measurements of the software. We measured it weekly, daily, hourly, sometimes more often than that, and we measured it across different axes. We measured page load times and launch times and memory footprint and the number of malloc nodes that we had. And we created massive charts and tables and we tracked this whole thing.

And we used the tools that come right on your developer's CD, real simple ones like Top and more sophisticated ones like FS Usage and Sample. And more importantly, we built our own tools and we built them right into Safari, right inside, because if you're not looking at performance from the inside, you're missing a lot of the picture about what's going on in your app. So we took regular measurements. And then with all that data, we removed the--. We removed the sloth.

Okay. We removed those cases of where we were doing work two, three times too often. Get it down to just--. You know, maybe just do that once. That's all you need to do. And even in some cases, maybe not even do that at all. And then, and only then, did we fall into the classical optimizing. Just get rid of the easy stuff off the top, and you'd be surprised at how fast your app can get with that kind of approach.

But I think most importantly, we never made it any slower. People always ask me, how did you make Safari fast? We didn't make it slow. Well, the truth is we never made it slower. We never regressed. If we had some huge feature that was going to land, and we tested it and tried it out, and if that was going to slow down the app, we didn't land that feature.

There was a big one that was going to go in last year that would have slowed down Safari by 7%. I told the engineer, sorry, can't land that. You've got to give me that 7% back. And he worked and worked. It went a week and a half. He got me 8% back. So I let him land it.

You have to do that. You have to have that policy. No regressions. Zero tolerance. That's why Safari is faster on every release. I'd really like, while I have this bully pulpit where you're all out there, you're listening to me after that wonderful lunch, please, please take some of these techniques back so we can have fast applications on this platform.

Okay, so, so Don, Safari is swell for users. It has all these great features, this solid quality, this impressive performance, but what's in it for us developers out there, you're saying? Well, as you've probably heard, we're opening up Safari We're opening up the hood and we're letting you at the engine this week.

Okay, because Safari is not just a browser anymore. We're taking the frameworks that were inside Safari and we're moving them into public locations in the system and we're giving them public APIs that you can all call. We're also providing you, the developer, a software development kit so you can use those frameworks and those APIs.

What are these frameworks? There are two of them. The first, you've probably heard about it already, talked about it in the conference, is the WebKit. This is the Safari content window. It's the big HTML widget. It's the framework that provides the embeddable browser views, how you can put Safari inside your app.

But there's another framework, our old friend Foundation. We've upgraded and enhanced it with brand new URL APIs for loading and other things. So when are these frameworks available? They're available now! Yesterday, as a matter of fact. They're built into Panther, and more importantly, they're in Jaguar as soon as you install Safari 1.0.

If you've got Safari 1.0, you go in there and get info in the finder and notice how it's skinnier now? That's because the engine is out in the system. WebKit is over in system library frameworks alongside a new foundation that gets installed. Okay, so who's using WebKit? Well, in Panther, that's going to be mail, so you can have beautiful HTML mail rendered. Sherlock, right?

and the Help Viewer. And I told you this is going to be nice for people doing Apple Help content. You've got the power of Safari inside of Help in Panther. But also-- Thank you. Xcode will be using it. Project Builder actually, I believe, does use it on the CD.

And hopefully, your application will be using it one of these days. Okay, so who's using these new Foundation URL APIs underneath? Well, in Panther, Software Update, that's how we download stuff for software updating. and Java uses it for cookies, among other things, and hopefully your app can use it too.

So when is the SDK available? It's available now! Right now. Yesterday, as a matter of fact, it went up, I believe it was probably a half an hour after Safari went online. And if you have one of them free ADC memberships, you can just go right over to the developer site and download the SDK, install that. It's got documentation, the whole nine yards, total coverage.

Okay, so where can you use the SDK? Where can you use these technologies? Well, you can use them in both Cocoa and, yes, in Carbon applications. Now, it's an Objective-C API, but the WebKit has a convenient C API for initializing WebKit and creating views. And plus, the SDK has plenty of examples, C and C++, adapter code included, that you can just lift and take out using your application. We made sure the license was liftable and reusable.

So what I'd like to do now is I'd like to have Richard Williamson, Safari engineer extraordinaire. Is that how you introduced him yesterday, Scott? Yeah, thank you. Come and do a demo of the web kit for us. Hi Don, thanks for that info. So the first demo I'm going to show you is actually a recap of the demo yesterday.

And so some of you may have seen it already. I want to put out one thing, though. The controller that we use isn't on the seed of the Panther CD. So keep that in mind. The first demo, we're going to build a codeless browser. That's what it's come to be called.

So I'm going to launch Interface Builder and start a new application. And you'll notice that Interface Builder has a new palette, the WebKit palette. I'm going to place an instance of that class, the WebView, into my window. And now I'm going to connect a URL to this web view. Using target action and two buttons quickly for back and forward.

Give these buttons a label and connect them again using target action. Let me set the resize flags on these buttons. And then we will test the application without compiling any code, without writing any code. It really is this easy-to-use web kit. So what I'd like to show you now is a demonstration of the binder technology, which I showed you yesterday, but it's worth a second shot.

So the first thing I'm going to do is disconnect the normal target action mechanism that we use to connect the text field to the web view. And instead, I'm going to use a controller, a web view controller, to bind The web view and the text field together to the same underlying property, the mainframe URL. So when the URL changes in the web view, it will be reflected in the text field. And to do that, I'll use the new bindings inspector after selecting the text field. And I'll bind the value of the text field to the mainframe URL.

Now, I'd also like to enable and disable the back/forward buttons as I navigate, and as it's appropriate to enable and disable these buttons. So I'm going to bind or associate the enabled property of the back button to whether or not the web view can go back and similarly can go forward.

Finally, what I'd like to do is add a progress indicator so I can see when the page loads and when it finishes. So let's add a progress indicator. "I'm going to size this text field so it fits. And we'll make the progress indicator determinate from zero to one. and bind it to the estimated progress of the page load. Set the resize flags. That's it. Again, no code, the codeless browser. Let's go ahead and run this.

Now you'll notice the back and forward buttons are disabled, the progress indicator shows the page load, and as I navigate, the URL of the text field changes. So that's the quick snapshot of how to use WebKit from Cocoa. But I've already had questions about how do we do this from Carbon.

So what I'm going to do now is show you-- A couple of applications that are already built, these applications with their source code in their entirety are available in the SDK as examples. So the first example is an application called Carbon Web, and this is a browser written using the Carbon APIs. Just to show you that it is no different than the Cocoa version, let me load a web page.

Now you see it's relatively full-featured. It has a history. It has back and forward buttons. And the final demo I'd like to show you is another Carbon application. This uses a combination of WebKit and new Foundation APIs to download URLs onto your desktop. Let me go ahead and load a page.

Well, you'd think it was that easy to do a web browser. We could have got Safari done sooner, huh? Yes, those guys have been sandbagging me. All right. Richard will be back. He's here all week. And he has a session which is a lot more in-depth on Friday morning at 9:00, right? Okay.

Let's give you an overview of the WebKit right now. First off, I want you to look at this incredibly simple architectural diagram. But really, the WebKit is that simple. I mean, Safari sits on top of the WebKit, and it uses the WebKit to display web content. The WebKit sits on top of the foundation URL API, and it uses that API to load web content. I mean, it's really not that much more complex. And Safari itself is, in a way, just a wrapper for the WebKit. But let's focus on the WebKit for now, and let's take a look at what's inside it.

two special frameworks, WebCore and JavaScript Core. Our two open source components, our engine. I'd like to talk a little bit about those at the core of WebKit. What we're doing is we're using open source from the KDE project. Now the KDE project is a desktop environment available on Linux and other UNIX platforms running under X Windows. And the KDE desktop has various applications and utilities and libraries in it. And one of those applications is the Conqueror Web Browser. And the Conqueror Web Browser uses two libraries in KDE called KHTML and KJS.

And we're using those same libraries. WebCore is basically an adapter built on top of KHTML. KHTML is the HTML rendering portion, and WebCore not only contains about, you know, 98% of the KHTML source, but it also contains adapter glue code, basically to connect it to the app kit and OS services and everything else underneath. The other framework is JavaScript Core. JavaScript Core is just basically a thin wrapper around KJS. And JavaScript Core is a JavaScript interpreter. It's the part that gives dynamic content to web pages.

Now we also have some other open source components in WebCore and JavaScript Core, including the XPAT XML parser, the PCRE regular expression library, and believe it or not, we've even got some Mozilla code in there. That always surprises people when I tell them that. It's not much, but we do have Mozilla code in there.

why did we choose to do the engine open source? Well, it's all about the technology. I mean, open source is a great development model. You get lots of people working for you essentially for free. You get lots of contributions from the outside and you get synergy going with a whole community.

But for us, the decision to use KHML and KGS was a technology decision. They're that good. And I'd like right now just to tip my hat to the KHML and KGS developers in the KDE project and thank them for their wonderful work. We really appreciate it at Apple. Because let me drill down on this a little deeper.

It's small. KHML and KJS combined are only about 140,000 lines of code. That's less than an order of magnitude smaller than some other web browser engines out there. That's a lot less code. And it's fast. Not only is it fast because less source code makes less object code, and if you execute less object code, well, you go faster, but it's just designed to be fast from the get-go. It's a really good design. But one of the things I really love about it is it's easy to modify. This is a fun code base to hack. It's just very straightforward, easy to understand, C++ code. You'd love it.

So what are we doing with the community, the open source community, with KHTML and KJS? Well, we're working with the KDE team. We've already had one transatlantic telephone conference call with them. We're on mailing lists together. And Harry Porton, who's the lead for KJS, has actually been out to the Cupertino campus and visited us. We know these people. We know them pretty well. They're very nice folks.

We're also giving back our bug fixes enhancements to the community. Apple is giving that back. If you noticed yesterday, one of the other downloads you could get is you could get the latest version of WebCore and JavaScriptCore because, hey, it's open source. Give that back. And we've actually been sending patches along the way back to the KDE team. And we're also taking contributions from them. Just three, four weeks prior to us releasing 1.0, we actually took a patch for a very small feature in KHTML itself from the KDE trunk.

We're also sharing ideas and plans for the future with the KDE developers. Like I said about our previous summit, we're going to have another one now that the Safari team has survived Safari 1.0, once we survived WWDC. We're planning on getting together again and figuring out what we do next, how to split up some work, and really take the engine toward the future. But you can contribute too to this engine, either to our WebCore and JavaScript Core projects, or to KHTML and KJS. We would love to see your bug fixes and enhancements too.

So, which frameworks should you use though? I mean, 'cause I've been talking up WebCore and JavaScript Core here, how they're great. Don't call them directly. Their internal frameworks, their APIs are guaranteed to change. In fact, David Hiatt must have changed them this afternoon knowing him. Don't use WebCore and JavaScript Core. Use the WebKit. The WebKit is the public API for WebCore and JavaScript Core technology. Okay. So what does WebKit provide? Let's get back to it as a whole.

Basically, the WebKit provides core classes to display web content in Carbon and Cocoa Windows. It can display by default MIME types like HTML, text, and images, but also things like plugins and Java applets. It simplifies the complicated loading process. It can request content from a server and download that in the background and manage the delivery to your application. Plus, it not only deals with the Internet, it can deal with local files as well.

It also has a default behavior, just like a web browser. If a user clicks on a link with the default view you saw in Richard's demo, it just loads another page. WebKit will create and manage all the views, destroying what it needs to, cleaning things up behind your back. It's got you covered.

So why use it? Well, many applications need to display HTML content, not just web browsers. Certainly web content editors for preview, but even word processors and spreadsheets and apps that I can't even think about yet. But more importantly, why write the code to do this yourself? I mean, it's a lot of code, but we built it into the system. We've made sure that it's optimized, it's fast, it's got a low footprint. It's not going to add to your startup time to call it. It's right there at your fingertips as developers.

Another reason to use WebKit is the fine standard support. We are fully buzzword compliant. We got your HTML4, your XHTML, your XML, your CSS1, 2, and even some of CSS3, DOM level 0, DOM level 1, DOM level 2. I mean, even if you don't know what all those means, it does sound impressive, I hope. We support HTTP cookies, JavaScript, Netscape-style carbon-based plug-ins, Java applets, secure connections over SSL, and for your text geeks out there, we do Unicode and bidirectional layout support. So we're fully--that's a lot of RFCs and W3C specifications I just named off there.

But more importantly, we're real-world compliant. Because the WebKit knows how to lay out the-- the world weird web, okay? Because, you know, I don't know if you go to some of those dark corners of the Internet where, you know, it's just about one, two grades above line noise out there.

The WebKit can handle it. It can handle that malformed content as well. But because there's so much of that stuff out there, we're working with the W3C on new standards. We want to make it better for web content developers out there. We have team members on W3C committees. We're committed to this for the future.

Okay, I want to cover some basic WebKit concepts. Four concepts: views, frames, loading data, and delegates. Okay, first off, views. How do you embed web content in your application? Well, you create a web view object. You attach it to a window, and then you send its mainframe a load request message. It's that simple.

WebView inherits from NSView, just like other Cocoa views, and if you're using it from Carbon, it acts like an HI view. It provides a no-code interface. You saw that in the Interface Builder demo. And it has plenty of hooks for customization, which we'll discuss shortly. A web frame encapsulates the data displayed in a web view. Every web view has at least one web frame.

And load requests are sent to this mainframe, as I mentioned earlier. Webframe objects are created by the web view. It manages them all for you. And webframes can be nested in a hierarchy, sort of like framesets on the World Wide Web. Webview manages that, and the root frame is called the mainframe. That's where you send your load messages to.

Loading data. Loading data into frames is handled by two foundation classes, new foundation classes, NSURL request and NSURL response. A request is just the URL to load and any options on that load. Options like whether it should use the cache, whether it should reload, what the user agent string is, things like that. And a response is everything from the server except the content. This is the metadata, like the HTTP headers, you know, times and other tricky little information there.

Delegates. Now this is where I think the real cool part of WebKit is. Delegates are how you customize the embedded view. Think of delegates like callbacks if you're a C programmer. Basically, excuse me, you create a delegate object that follows an informal protocol or an interface and you attach that object to the web view to handle things for you. There are four delegates for web views. The first one, the web frame load delegate. This tracks changes to what page you're on. For example, when a page starts loading, it stops loading, it fails to load, and it tracks the transitions between pages.

The next delegate is the Resource Load Delegate, and this tracks the loading of sub-resources on the page, for example, images. You could create one of these delegates if you wanted to block images, or you wanted to load a completely different image than the one the page specified. You might implement both of these delegates if you wanted to do progress feedback. And if you look at the source code to one of the examples we have on the disk, that's actually what's done for progress feedback. The third delegate is the Policy Delegate. This handles navigation actions like clicks and form submissions and back and forward.

"And you can basically with the policy delegate either let WebKit handle the content internally, or maybe you want to intercept that click and say, 'I don't want to download you at all. I'm not going to allow the user to click on that link.' Or maybe instead of loading it within your app, you want to download it to the desktop. You could say, 'Download that,' instead of displaying it."

Then there's the Web UI delegate. That manages all window and user interface activity. It controls the opening of windows, and you can actually use it to control context menus as well, like add items to context menus. And any application that's going to handle web views in multiple windows is probably going to want to create a Web UI delegate. Now I'd like to call Richard Williamson back up to the stage to show you a demo of that very thing.

Okay, so you see the codeless browser. Now we're going to write some code. Before we get through this presentation without seeing any code, we have some code that we're going to write right now. And what I'm going to do is show you In Xcode, one of the sample applications that is on the SDK And we'll modify it. So let me first run it to show you some of the features. Now, you'll notice that this mini browser has a few additional features than the codeless browser. Up in the title bar, I'm showing the number of resources that were loaded, 43 of 43.

That was done using the resource load delegate. You'll also notice that, in this case, as I navigate, The URL does update in the text field. I didn't use the controller technology. I didn't bind the URL to this field. I used the delegate to set that with code. I used glue code to do that. And that glue code is visible in the SDK. Now, let me go to the New York Times site.

and show you some of the built-in context menus that the WebKit has. In this case, open, link a new window, download to disk, and copy link to clipboard. Now, by default, the WebKit will show this context menu, but there's no implementation behind it. It's your responsibility as a client of WebKit to open a new window with your Chrome and your instance of WebView. In fact, it might not even be a window.

You could change the title of this context menu, and you may open a link in a tab, for example. But in this case, let's go ahead and try and open the link. Nothing happens. That's because the UI delegate isn't set up to handle a new window. Let me go back to Xcode. And if I can get a handle on Xcode, let me bring up the editor.

And open up the source for the document. Now, this document is using the NS document infrastructure. And you can see that-- I'm setting up two delegates, the Frame Load Delegate and the Resource Load Delegate. These are the two delegates that handle showing that progress in the title and changing the URL. What I'd like to do is add a UI delegate. So I'm going to cut and paste this code that happens to be down here, just below, and add myself.

and David Levy, I'm going to show you how to use the API for these delegates. The API for these delegates is really rich. By default, you don't have to implement anything. There are default behaviors for all of the delegate mechanisms. I'm going to override one method. This is the method we use to create a new view.

So WebKit will send this in response to a request, either from the context menu or perhaps from JavaScript, to open a new window. And what I do here, simply, is to use the NSDocument infrastructure to create a new document using the standard document controller. That will open an untitled document, which in turn will load a Nib file.

That Nib file contains the web view, that you can see I retrieved from the document down below. And then simply, I load the request into the mainframe of that web view. That's all it takes. Let's go ahead and compile this. Yes, I'd like to save. And once it's compiled in link, let's run it.

So let's try a different site. How about Wired? OK. Now, if I bring up a context menu over a link and open a link in a new window, I get a new window. Simple as that. That's it. So there's a lot more detail that we'll show you on the session on Friday, but this gives you a sense of how to use delegates in the WebKit. Thanks, Don. Don Taylor: Thank you, Richard.

Oops. OK. Oops. Here we go. Click on the demo button. OK. I'd like to give you a little overview of the Foundation API. And let's go back to one of those simple architecture diagrams once again. Safari and WebKit at the top, Foundation in the middle. And I just want to focus on the fact that Foundation, the URL API, sits on top of CF Network.

That's where it gets its implementation. And that sits on top of BSD Sockets. Okay. But let's focus on that API. It's a very, very simple stack, standard stuff. Okay. So what does Foundation now provide? What have we added? URL loading, one thing. We've already talked about that a little bit.

But also content caching, so you can get fast access to web pages and other Internet data. Cookies, so you can do all the sorts of e-commerce and complicated web application work. Authentication, so you can get into the site securely. And custom protocols. You can add your custom protocols now.

So why use this API? Well, the features I just mentioned before, the convenience, because it does a lot of work for you, flexibility, much like the WebKit, it's very, very flexible, and the performance, even better than before. So let's talk about the convenience first. Just like the WebKit, the Foundation URL API has smart default behaviors. It just does the right thing for you by default.

It has automatic handling of cache and cookies. If you're gonna write a little command line tool to download URLs, guess what? You've got the power and behaviors of an entire web browser behind you if you want it. Our cache works per application. You can decide where that's stored on the system. If you don't decide, a nice default spot is picked for you.

And cookies are per user but they're shared. I'm sorry, they're per user but they're shared across applications. and it also has nearly automatic handling of authentication. If you want to get basic and digest auth, things like that, all you have to do is just implement two callbacks, basically two delegates.

For flexibility, it has methods and delegates to control just about everything. Request options that I mentioned before, things for reload and offline modes, you can get very clever there. You can get direct access to the cache if you want. And if you want to get funky with the cookie manager, you can make multiple cookie policies just like Safari has. Always accept, always reject, you can do an ask policy if you want. Plus, we allow you to add custom protocols. We provide the standard HTTP, HTTPS, FTP file, and the all-important about protocol. But you can add your own using the same API that we've used.

But the performance, if you thought it was fast before in Jaguar, it's even faster now. Fast URL loading is essential to fast web browsing, and we're going to keep making that better. So let me cover some other Internet technologies since we've got through the WebKit and the Foundation URL APIs that I want you to know about.

And before I move on to this, I just want to mention one of the sessions tomorrow when I was talking about Web standards. I forgot to mention there'll be a session, 10.30 tomorrow morning, Safari Technology and Web Standards. I have no idea what room it's in, but John Galinzi knows. So the first technology I want to talk about, CF networking.

CF network, we like to call it all the networking knobs and buttons. It has a nice core foundation style C API. Don't forget about that. That's what's underneath the foundation API. That's what foundation is implemented on top of. It has protocol abstractions for sockets, for HTTP, even for rendezvous. And in Panther, we're adding DNS host resolution and support for the FTP protocol. Also, we have a Web Services API. This is how you do XML, RPC, and SOAP on Mac OS X. And in Panther, we're adding a server-side API.

Also Sherlock, the easy way to deliver platform compelling web services. I like to call it web services for the rest of us. What's new in Panther? We've added a channel browser like Safari Bookmarks. It's a whole organizer. Not only does it contain the standard Apple channels, but it can contain your third-party channels.

We've created also a new easy channel submission mechanism. We think this will give you high visibility for your web service in Sherlock. We've also improved performance dramatically. Faster launch and channel switching. It's very peppy. And we have a new standards-compliant XQuery engine that's two to three times faster than the one in Jaguar.

Okay, let me cover just very quickly some other technologies that maybe you shouldn't use anymore. These are no longer under active development. HTML rendering lib? No. Use the WebKit. That's why we put out the whole Safari SDK. NSURL handle, while it still works and has been reimplemented on top of the new Foundation APIs, it's not where the future is.

URL Access Manager, please say no. Please use CF Network for some of the low-level operations and the new Foundation URL APIs for everything else. Also, Internet Config, you don't really need to use it anymore. Launch Services can set up those helper applications, and System Config can be used for just about everything else.

Okay, in summary, just to make sure everybody got it or they came in late, don't forget the WebKit can put a browser view in your application, and Foundation now has upgraded URL APIs at your disposal. So please create some great applications using these technologies for Mac OS X, things nobody has ever seen before. That's what will really thrill the Safari and the Internet Technologies teams. Thank you very much, and I'd like to bring John Galinzi back for the wrap-up. John.

Thanks Don. Why don't we call the Q&A panel up while we're getting-- The road map there? Yeah. OK. But while we're going through the road map. Q&A folks? All right. So for the benefit of those who would be watching this session on DVD someday, there was a session this morning, open source at Apple. There's a pile of other sessions that are coming up later this week or later today related to internet technologies at Apple. So Safari Technologies and Advanced Foundation URL, Advanced Webkit APIs later on this week.

Delivering web services using Sherlock channels. And then overview of networking APIs. So it's really important in the age of Panther to make the right networking API choices, as well as a variety of other API choices. There are the right APIs to choose and the wrong APIs to choose nowadays.

So a lot of these sessions are going to be great for giving you that kind of guidance. And finally, if there's any feedback you have on the APIs related to Foundation URLs or WebKit or anything you've heard in this session that you want more information about or working with Apple on the Safari technology side of the house, feel free to send me an email, and I'll get you plugged into the right people.