I'd like to welcome you to session 110, Overview of Mac OS X Networking APIs. My name's Tom Weier. I'm a consulting engineer in our field engineering group, and I have the fortune of introducing this session. There's a lot of things in Mac OS X that have changed over the years. A lot of new features have come into the operating system, and there's a lot of material in this session. As you saw in the keynote, we have new VPN functionality, new enhanced support for IPv6, and a number of other key features. So with that, I'd like to welcome up Vincent Lubet, manager of CoreOS Networking.

Good morning. So this is what we're going to go through today. So we're going to start with a brief overview of the Mac OS X networking, a little bit the architecture, what's the new features, and then we're going to delve into networking APIs. There are a lot of networking APIs, so it will be relatively high-level, just more a list of features, and maybe, hopefully, you will have some idea which, depending on your needs, which API to use. And basically, we have system-level APIs, and then also framework APIs, framework-level, and Becky will do the second part, talking about the frameworks.

So we have ongoing goals, and they haven't changed since last year and the year before, I think. So the ease of use, we'd like to have the networking be as transparent as possible. So one great example is Rendezvous and other zero-conf effort. Performance, also, is very important. We have the same kernel that runs on a laptop, run also on an XR. So performance and scalability is an ongoing goal for us. Extensibility, that's a common feature from you, from a lot of developers. And also standards compliance. Whenever we can stick to standards, we would like to do it.

So the core of the networking is in the kernel, that Darwin layer, and basically that where you have the Apple Talks stack that is not used very much these days, but also the TCP/IP stack. And all of that through the core services and a lot of framework serves the application's environment.

So, Mac OS X, the stack is based on FreeBSD. Last year, we updated it to FreeBSD 3.7, I remember, something like that. No, 4. And so with that, you get-- so it's a Unix-like-- The TCP stack includes IPSec and IPv6. We introduced that last year already, so we still have support for Apple Talk, a full remote access suite of protocols based on PPP. The stack comes with a firewall and also NAT daemon.

The cool stuff we have added to Unix is this dynamic configuration based on the frameworks with plugin architecture, so that as far as we can, we're trying to push the system so that the configuration reconfigures automatically. And of course, we have Rendezvous, and that was the major breakthrough of last year.

So what's new in Painter? So more rendezvous-aware applications and services. So if you went to the Stuart session yesterday, you saw a lot more applications in Painter. You have iChat, iTunes, Safari, and more. We have also more IPv6-aware applications and services. One of them, so for example, AFP, the one that you have in Painter, runs over IPv6.

We are introducing also an IPSec-based VPN, 802.1X for link layer authentication, even better support for mobility and WebKit and all the Safari framework, and a lot more. So we're going to go through a little bit. So 802.1X is a link layer authentication. That means that that's a user authentication that allows, that runs, before really your link can go up. So it's really the... coming to be the prevalent way to secure wireless LANs.

But it's also used in some switch environments for ethernet. And in Panther, we support a wide range of authentication methods. 822.1X is still a young protocol, so it's not clear which of those authentication protocols will be the prevalent. But we support all that list. That are the ones that are used by Cisco, Microsoft, and other vendors.

The Apple VPN, so it's a client and server. And so we use IPSec to provide really the secure layers. And we use also L2TP for interoperability. L2TP is, in fact, it's running PPP over UDP. And that provides interoperability with Windows, Cisco, and things like that. That's really the really the only standard VPN protocol out there. And so we prefer AES for the encryption.

For those who know the cryptographic algorithm, it's more efficient. But we still support triple DES and other algorithms. And we have also added support for SecureID. It's a very popular way to provide user authentication. So I think that's a lot of -- it's deployed in the company. But we have also other support, MSCHAP, V2, and things like that.

So we have a different level of networking APIs, so that's just a short list. And we're going to go through that in the rest of the session. So first, I'm going to start by the bottom, if you like, that are the system-level APIs. It's more or less what you find in Darwin, the open source implementation. So I'll start with the BSD Socket. So that's the fundamental APIs for networking. Everything else is mostly-- every other networking API is based on BSD Socket. And so that's the one you use to get the most out of the system.

That's the raw access to the kernel. It's done via Socket. So when to use Socket? For performance. So if you're in server environment, if you're writing a server application, you can use You have the insurance to have the most of the system. You have very fine control of what's happening.

You have access to all the low-level controls, complete IPsecs, PF and DRV, and things like that. We're going to talk about that. And also, BSD, so it brings you Unix compatibility and portability. On Windows, they have WinSocs, relatively close, so often it's a good way to ensure portability.

With the BSD Socket comes the resolver library. So it provides name and address resolution. In fact, there are two levels of APIs. Some of them work with other name systems, not only the DNS. And it goes on and on. So with the Socket API, in Panther, it's been updated to bind line, so the latest and greatest. And we have also full IPv6 support. That means that you can resolve an IPv6 address using the resolver functions. But also, you can resolve over V4 and V6. So it's the full set.

So IPv6, so we implement the standard APIs. It's part of Socket. It's an extension of the basic Socket API. Something that we turned off that was a nice-- Functionality was mapped address that we're able to use when you were a server. You were, for example, people were using just one socket, a V6 socket. Because V6 addresses are larger than V4 addresses, with this option of mapped address, you could have also, receive also V4 connection on that socket. For security reasons, we disabled that by default. It's off, it's not disabled, but it's off by default.

Because there are some security reason implication, there are some implementation out there that in fact, We use Tunnel, really. It's a way to tunnel v4 in v6, and sometimes it bypasses firewalls, and people are not very happy with that. So in Panther, it's by default. There's still a socket option, if you know what you're doing. You can use it. Mac OS X doesn't tunnel v4 in v6, but there are other implementations that do. And so we have the DNS over IPv6 in Panther.

And so the idea here is for application last year, we had a full office session on IPv6 and how to code for address family independence. It's really easy to write programs that support both v4 and v6. That's why those APIs are standard, and we encourage you to do that.

And so one of the great stuff about v6 is rendezvous. We have a team who works over IPv6, so it's a very easy way to find out services and test stuff on the network. You don't need to have... With IPv6, you don't need to have an infrastructure. V6 automatically configure addresses, link local addresses on all the interfaces, so you can find services. It works perfectly with multi-owned system.

IPSec provides IP-level security from within the kernel, the bottom of the stack. So we support a bunch of... There are a number of APIs to set those security policy and association database. Those are the kind of the filters that tells you what traffic to encrypt using IPSec. There's the PFK socket.

IPSec set policy, it's a library function. And also you can have a per-socket control. So we saw a few, already a few in Jaguar, a few application, third-party application using IPSec. So the new thing is that in Panther, we're also using IPSec for our VPN. So there is something that is... Something to remember is that this is a single shared system-wide resource. So, and it's managed by the internet key exchange, the one, the protocol that exchange the keys managed by a single daemon called Raccoon.

And so it's a single resource. So please, if you use IPSec, make sure you don't override preferences or settings from other applications. And we've added also Net Traversal in Panther. That's something that really, in this data, in these days, with that is prevalent. And so we support that. That's the, it's not yet a standard. It's still a ITF draft, but that's what we, that's the best, that's the best solution.

That's the way to traverse NAT with IPSec that's most likely to be interoperable, although it's not yet a standard. So we have an IP firewall that works also with IPv6 in Panther. And again, just like with IPSec and Raccoon, it's a single system-wide resource. So with IPSec, you can define filters and actions to do on certain types of packets. But just remember it's a single, wide resource.

And just like, so for example, you've certainly noticed that the built-in firewall will not turn itself on if it detects there are other rules on the system. So be nice and don't overwrite other people's rules. Or you can ask the user if he wants to flush. There are two ways to control the firewall: a command line, a PFW, and also just straight socket options.

PFND RV Sockets are sockets that allow us to write user space protocols. That means that's a facility we have in the kernel, using these types of sockets, to send raw Ethernet frames up to user space. And we use that with 822.1X. It's an Ethernet protocol, in fact. And so that's a great way to stay out of the kernel. And it's also used to implement other protocol stacks that are maybe specific for an application like DECNIC or IPX and others.

There are other solutions that you also can be used. It can be used instead of PFND RV Sockets also to implement user space protocol. Those are listed to the diverged sockets that work with the firewall. And NBPF, the Berkeley Packet Filter. So... We, given the state of the internal API for network kernel extensions, we really like, if possible, that you implement your protocol in user space, if possible, so that you can be sure that there's no problem of compatibility in the future.

So let's talk about the problem, I mean, the network kernel extension. So today, the NKEs are tied to the kernel implementation. So we cannot really say that we have an API. It's really-- we provide hooks where extensions can really get to the internal mechanism. That's fragile. It's going to break.

It broke in the past. And every time we implement a fix, for example, or want to improve performance, we have to think about, is this going to break a third-party kernel extension? So if you came to the session about the kernel yesterday morning, you're certainly aware that we are working on a new API that will isolate extensions from the internal implementation of the kernel. And it's not yet ready. It's underway. And we certainly like your participation and feedback, because we're going to do certainly some drastic change in there.

System configuration. So that's the foundation for our mobility solution. And it's based on a daemon and a couple of set of APIs. So we have a set of APIs to manage preferences. That's the one that I use, for example, by the network preference panel. So those are system-wide, local preference for this host.

And we have also an API to get the status about the state of some parameters. So that's the basis for the dynamic behavior. So there are notifications when there's a change in the state of some data or key or the preference. And they are used today also by a lot of third-party applications, for example, ISPs, ones who provide their own dialers. They use that. And also application. That's how they can dynamically react to a networking change using the status. And it's used, for example, by Mail and Safari. And also it's the basis for the dial-on-demand.

So what applications they use usually, so the preference API I just talked about are more used to manage the configuration, but we have an API called the ASC Network Catchability API that allows to check whether a set of maybe NAM addresses or pair of addresses, NAM in Panther, are reachable. Rich Ability, it's not a guarantee that, for example, the distant host is, you can really connect to a distant host.

But what it says is that from the standpoint of the system locally on the machine, there's an IP address, a router is there, maybe there's also a DNS server configured. And so it's this API, so Unify, a set of information, you know, it gives you a synthetic view of it.

Um... So when to use SC Network Catchability? So just to tell you if you have a chance to connect to the server. Maybe the server is-- so it will not tell you if there's a firewall, if you have a problem with NAT or things like that, things outside of the control of the system. But at least it can tell you the system is properly configured.

So when there are changes in connectivity, that's you have the chance to clean up, and maybe to provide some feedback to the user. For example, CFSocketStream use that on every socket. Becky's going to talk about the CFSocket API a little bit later, but our own frameworks use this API as its base API.

So something new in Panter that works, in fact, with the reachability API is the SC Network Connection API. This is the API that enables dial-on demand from within the application. And it's similar to the OTPP remote access API we had on Mac OS 7 and 8.9. So the idea-- so today, what we have is really something that we call at Apple dial-on traffic. So if you enable that preference in PPP, the PPP, every time it sees that some data is to be sent, it will dial the modem. And that's the cause of a lot of complaints, because it's the system dials at the most unopportune times.

So what we want to do is, instead, with having this new API, to enable application developers to-- to be in control. And they can decide or maybe prompt the user. So I need to get on the network. Do you want me-- this request to dial. Do you want me to dial? Yes, no. And so, for example, it's great for male clients.

And also, that's the same API that is used not only for application, but also for dialers also, with different set of parameters. Internet Connect, our own Internet Connect in Panter, uses this API. So really, we would like you to adopt this API. So I put together this little sample code. It's just to show you how simple it is.

So, for example, this is how to tell if you want to, for example, to access www.apple.com, what you would do, you would call sc_network_hability_create_with_name, so where you pass the server name, and then you specify a callback for this reference, you get back a reference, and you specify your callback. So when there's an event that happens for the change in the reachability of www.apple.com, your callback will be called. And you just schedule it with your run loop, so it was great for applications above the BSD layer, let's say, and you just run the run loop.

And then this is the reachability callback. When you get an event, basically, The major event is the flag that tells you. It's a set of flags you get, but the one that's really interesting here is whether it's reachable or not. There are sub-flags, and one tells you if a connection is required. And now in Panther, if the server -- so if you need to start a connection, you just have to use the connection API.

And the Start Connection API, usually when you are not a dialer, you just want to use the default, certainly the most current connection the user did with Internet Connect. So you just tell the user, just copy the current preference, and you tell the system to create a reference again, because that's kind of the hook, the endpoint that you will use.

And again, it's an event-based mechanism, so you schedule in the run loop, to to be ready to receive event and then you you call the the start and you release the stuff you you don't need and again when there's an event on the on the connections you're being called back and here the the main event you you have it's very similar to the remote access api and it's just so if it's disconnected connecting connected disconnecting and in case of error you get invalid but and when you're done you close the connection so the one point in the in this api the the connection as are raf counted that means that the idea is that the when the the connect when your application doesn't doesn't need to to use the the system certainly you would like to the the modem to disconnect so you just release the connection if there was another application using the connection it will still hold the reference on the connection so the it's on the on the last reference that the connection will be turned on And with that, I'd like to... Oh, no, one more thing.

Last but not least, that was my... It's the DNS Service Discovery API, so those are the rendezvous APIs. There was a session yesterday about... Oh, something is wrong here. The session is not kernel programming, but that's the Rendezvous API. It's 102. So the NAN service discovery APIs are the foundation for Rendezvous, and you have sets of APIs to register NAN services. Also an API to browse for services. Rendezvous is really something for end users.

So that's the idea, is that the end user will pick and choose a service. It's not so great for background connections, because really the idea is that the user chooses, browse something, and just remember the name. And then when it's time to connect to that service, you have an API to resolve, and the service into an address on the port you can use in subsequent, for example, Socket score.

We have three API flavors, depending what level your application, what type of API your application is using. So we have the DNS service discovery API. It's a system-level API. That's the foundation for the other ones. In CF Network, there's the CFNet services. So if you have a run loop, it certainly could be the natural way to use. And in Cocoa, there's NSNet services. That works for Cocoa. It's Objective-C. And now with that, I'd like to introduce Bikki Woolrich, who's going to talk about frameworks.

Thanks, Vincent. So Vincent has taken you through the basic feature set of what's available direct from the Darwin system, what's available at the Berkeley Sockets layer. And what I'm going to do now is talk about what we've built on top of that into the framework layers above it.

So I was thinking about how to prepare this talk, and it seemed with the introduction of Safari 1.0, the best way to look at those APIs was to look at what Safari has built upon. And that's how we're going to start out. After that, I'm going to talk briefly about some of the other networking technologies on the system. And finally, I'm going to give you some tips and hints on how you can transition off some of the older Mac OS 9-based APIs.

So let's talk for a moment about the Safari technologies. When we started writing Safari, we, of course, built on the technologies we already had built on top of the existing APIs. But we also discovered a lot of places where those APIs were lacking. And so we developed many new APIs at the same time.

And now we've made those APIs available to you. That's part of the Safari SDK. As you've already heard from the keynote, those APIs are available on any Panther system and on any Jaguar system, provided Safari 1.0 has been installed. And I do not have enough time to go into those APIs in great detail.

So I'm going to point you to some other sessions as we go, including session 403, which took place on Tuesday. But when you get the DVDs, you can take a look at it. Don Melton gave a pretty good overview of all of those APIs in greater detail than I'm going to have time for.

So what goes into Safari? It's on Mac OS X, so you know the core of the networking has to be BSD Sockets. But there's a lot of stuff between Sockets and what ultimately is the Safari application. And the first layer in that stack is Core Foundation. Now, Core Foundation provides a couple different important things. It's not really a networking library per se, but it provides a couple basic abstractions for us.

First and foremost, the run loop. The run loop is how all of the different interesting events inside an application get funneled into a single callback mechanism on our system. So if you look at NSRunLoop or Carbon Events, that's how user events ultimately are transmitted. And it provides our basic asynchrony mechanism.

CFURLs, Basic Abstraction for URL, Pure Data Type. And those two kind of come together with CF Socket, which provides a way to take a socket, a file descriptor, and connect it into the run loop. So rather than having to manage a select loop yourself or a file descriptor set yourself, you can use CF Socket to get that input managed in the same way that all of the other user events are managed. CF Socket can handle literally any socket. It works with most file descriptors, too, but we only promise it with every true socket. That includes UDP sockets, as well as server-side accept sockets.

Built on top of CFSocket is CFStream. CFStream is just a basic stream abstraction. You get a stream, you open it, you read it, eventually you close it. If you're unlucky, it errored out somewhere along the way. It's hooked into the run loop so that it can signal the client, your application, whenever bytes are available or something interesting has happened. However, because it's a stream-based API, it only really works with TCP sockets. It doesn't make much sense to talk about a stream for an accept socket or a UDP socket.

So that's Core Foundation. If you take a step up from Core Foundation, we get to CF Network. CFNetwork is the library on our system that provides the basic protocol implementations. This is where our HTTP stack lives. This is where the FTP stack lives. CFNetwork itself does not actually provide the SSL implementation, but it provides all the hooks into SSL and TLS. So if you've got a socket stream, you want to make it secure, CFNetwork provides the hooks to run SSL over the socket stream. Finally, Rendezvous. Vincent mentioned CFNet Services, which is the API that CFNetwork provides for accessing Rendezvous.

The basic goal besides CF Network is to provide you with those protocol implementations and hook them into the run loop. However, our goal with CF Network was not to be the most convenient API. There are higher-level APIs that provide that convenience. At this level, we're trying to give you full control.

What that means is that all the protocol details are fully exposed. So, there's a lot of power implied with that. There's nothing you can do with HTTP, for instance, that you cannot do through CF Network. But, on the other hand, you better know HTTP or the CF Network APIs aren't going to make a lot of sense to you.

Other ways we give you full control: At the CF Network layer, you have complete control over precisely when the reads and writes are done. Again, this can be a pain if you're not actually interested in the details, but if you need that control, this is the layer to get it at. Likewise, the threading policy: We do not dictate a threading policy for you at this level. At higher levels, we'll see some APIs that will actually take care of spawning background threads for you, for instance, but not at this level.

A couple things new in CF Network with Panther: We've added DNS host resolution. This is asynchronous host resolution, so you can start a request to look up the address of yahoo.com or anything, and you'll get a callback later on telling you when that address is available. We've also added FTP support inside CF Network. For more information about CF Network, come to session 112 tomorrow afternoon at 5:00 PM.

Yeah, okay, last talk of the conference, but what do you want? Okay, so what do we have above CF Network? Well, I mentioned some convenience APIs that do not expose as many of the details to you. That's what these new Foundation URL APIs are all about. So, new set of APIs in Panther. It's a full-featured set of URL loading APIs, and here, the point is for the API to be as convenient and abstract as possible. So, the policy is to make most of the choices for you.

Does that mean that you can't modify those choices if you want an unusual setup? No, of course you can. But the policy is going to be to start out by making the most common decision for you, and then you kind of have to undo those decisions. Whereas at CF Network, the policy was that you have to apply each and every policy decision yourself.

The API is asynchronous, building on the run loop, of course. It's basically callback-based. If you're familiar with the Cocoa API paradigms, we do it via delegates. And at this level, we add extensibility via subclassing. So if you've got to have the Gopher scheme implementation, we don't provide it for you, but there's a class you can subclass to implement it yourself and get it plugged into the entire URL loading system.

And again, it's part of the Foundation library, so it's built right into the core and available to you at that layer. And for more information about these, go to session 418 this afternoon, where we'll be talking about these APIs in much greater depth than I'll have time to go into here.

But just to give you a flavor for the API, here are the basic abstractions. You start out by creating an NSURL request. This encapsulates everything, all the information needed to configure a URL download. So the URL itself, if you have a custom user agent and you're doing HTTP, you can set it there. Proxy settings, all of that goes into the request.

Once you've got a request, you build a connection from the request. The connection represents the ongoing download. The connection has a delegate. That's the NSURL connection delegate. And you use that to get information about how your connection, how the download is proceeding. Finally, what you're going to get back from the delegate is the data, of course, but also an NSURL response object that encapsulates everything that's not actually part of the data. So that includes things like the MIME type, like the HTTP headers that came back.

And then I just want to highlight briefly the other features that are built into the Foundation URL APIs. I've listed each and every class here, but I'm just going to talk about the major bullet points to explain the features. Caching happens automatically with this API. There's both an on-disk and in-memory cache available and used. Cookie storage and management, all handled automatically, all shared for a given user across all applications, unless there are preferences to change whether your particular cookie is stored. But by default, they'll be stored so that all applications can access them.

Authentication and credential management, we've got a bunch of classes built in so that you can know exactly who's asking for a password, whether there's a password already available on the system for your use, and give you everything you need so you can prompt the user in your system. So you can prompt the user and get that password if necessary. And finally, the extensibility I mentioned. So there's a class available, NSURL protocol, that you can subclass if you want to add your own particular scheme that we do not provide.

So that takes us all the way through the URL loading APIs. The last piece, of course, is WebKit. WebKit is new in Panther. It's a brand-new public framework. And this is the layer that actually does all the rendering and navigation. So it's what actually draws to the screen and interprets the user events, as the user clicks or moves throughout the document.

It's a fully-pluggable architecture, so that you can support rendering new kinds of document types. We, of course, handle HTML text and the image types out of the box. But in fact, we provide sample code in the SDK that shows how you would extend WebKit to be able to display PDFs.

It's an Objective-C API fully integrated with the AppKit classes. So, in fact, the central class WebView is a subclass of NSView. The SDK also provides a bunch of example code that shows how you can take that WebView and use it from a pure C or C++ API and integrate it fully with Carbon HI views and Carbon events. For more information about that, there's a session tomorrow sometime, I'm not sure when, but session 420, they're going to go into the WebKit APIs in much greater detail. And that's the full stack. That's what goes into the networking portion of Safari.

So now I'm going to touch briefly on these three other networking APIs: Web Services, NS Stream, and Launch Services. Web Services is a framework we introduced in Jaguar. It provides APIs for issuing an XML RPC or a SOAP request. In Jaguar, the API was very focused on the client, so if you were a client and wanted to issue such a request and receive a response from the server, we had APIs for that. But starting in Panther, we've added support for server-side operations, so if you're on the other side of the equation and need to interpret an incoming request, we can now help you do that.

NSStream is new in Foundation in Panther. It's actually two different classes: NSInputStream and NSOutputStream. They're toll-free bridge to CFReadStream and CFWriteStream, which have existed for a while. And the reason why that's important is because NSInput and NSOutputStream is designed for subclassing. So we've received a lot of requests saying, "Hey, I don't want to talk to a socket," or, "I need to interpose a data filter between the actual bytes coming in from the network before you start processing it. How do I do that?" Well, you can't really do that with a C API, but with NSStream, we now have a way to do that.

Just subclass NSInputStream or NSOutputStream, insert the filter or extra data processing you need, and then thanks to toll-free bridging, you can take that object and pass it directly into the APIs that consume read and write streams. And this was touched on briefly at session 410 yesterday, the Cocoa update, where they talked about everything that was new in Foundation and AppKit.

And finally, Launch Services. Well, most of you are familiar with Launch Services as the API you use if you have a file and you want to open it exactly the same way Finder does. So you're probably thinking, "Well, what the heck? That's not a networking API." Well, the fact is that Launch Services is good at finding helper applications of all kinds, not just for files.

So the Launch Services APIs can be used to open an arbitrary URL as well, or to find out what application would handle a particular MIME type. In fact, Internet Config, which is an older API that you may be more familiar with, calls through to Launch Services to handle these kinds of services.

And so I mention that, of course, to get to this next point. We have some older APIs, some legacy APIs, that we're kind of interested in getting you to transition off of to some of the newer ones. And Internet Config is one of those. Are we taking these APIs away from you? No, of course not.

They're still on the system. They'll continue to work the way they always have worked. But we're no longer extending these APIs the way we're extending some of the newer APIs that I've just talked about. These are the four I'm going to address in particular: URL Access Manager, NSURL Handle, Internet Config, and OT.

So URL Access Manager. Clients tend to use it in one of two fashions. Either they have a one-off, well-controlled transaction, or they're doing some kind of longer-lived transaction. If you're in that one-off case where you know exactly the details of what you want to do, you know you're performing an HTTP post to a server you control, you set up as part of your business, CF Network is probably the best way for you to go with something like that. It gives you full control of the details.

At that kind of level, the extra abstraction almost gets in your way, because you know exactly what you're trying to do. On the other hand, if you want an API that's simpler, kind of one-shot, fire and forget, NSURL Connection is the way to go. And then if you're using URL Access in the other way, where you're performing some very long-lived, complex transaction, where you don't want to handle the details, NSURL Upload and NSURL Download are the two new glasses in the URL loading APIs that are available for that kind of functionality.

NSURL Handle in Foundation. The new URL loading APIs really supersede NSURL Handle, so use NSURL Connection instead. We've added a compatibility shim that connects the two engines, so if you have some investment in a URL Handle subclass, that'll continue to work as it always has. And not only that, anyone using the new API, the URL Connection API, will automatically see and talk to that subclass as well. Works in the other direction, so if you have a URL Handle-based API, you'll actually see and call through to the new Foundation loading engine as well.

Internet Config. So if you're looking for a helper app, you're just trying to figure out, who should I use to open this URL, or who should I use to handle this MIME type, call Launch Services directly instead. The other thing that we see in Internet Config is access to these system preferences, things like the proxy setting. To get those, talk directly to System Configuration instead.

Finally, OpenTransport. We've been telling you for at least three years now that OpenTransport is not your high-performance native networking solution on this system. BSD Sockets is. So as you're writing new code, we encourage you to use Sockets directly. Also, when you're choosing your networking code, maybe Sockets is not the right layer for you, and we encourage you to think about whether one of the higher-level APIs that's going to provide connection to the run loop for you will maybe serve your needs better.

So that's all the material I had for today. I want to continue to repeat this roadmap. I've talked about most of these already. I did not talk about 4.11 Internet Technologies, which talked a lot about the Safari technologies and the web in kind of a general sense. That took place yesterday. Vincent mentioned the Rendezvous talk, also yesterday. Kernel Extensions, CF Network In-Depth is tomorrow, and then the Feedback Forum. So if you don't like all of what I just said, come tomorrow morning at 10:30.

Some contact information there. And with that, I'd like to ask Tom Weier back up on the stage for the Q&A. Oh, sorry. I should mention the documentation. There's a load of documentation for the different networking available. Go to ADC Home Documentation Networking, and pretty much every API I've talked about here, everything that Vincent talked about, has documentation under that heading.