Oh, there you go. Okay. So for those of you who saw the keynote yesterday, you probably noticed that Apple's been rather busy this year. And open source has certainly been no exception for us. So there's going to be a veritable cavalcade of speakers coming up here after me to describe their various projects. But I'll give sort of a general overview and introduce the first of them.

These are also some important resources. As always, you can find our most recent Darwin sources and pointers to other important open source projects at developer.apple.com. OpenDarwin.org is another project we launched about a year ago in cooperation with the Internet Software Consortium. So you can get information there at OpenDarwin.org, and that's been very successful for us. And then, of course, we have our wonderful Fink brethren, who have a Fink.SourceForge.net address. And then, of course, have to mention FreeBSD.

Yay! So let me talk a little bit about OpenDarwin. They've started doing something we really hoped could be done by an external but yet loosely affiliated project, which is producing their own Darwin standalone releases. Those of you who ran the Apple Darwin releases might have noticed that they tended to come out fairly seldom, and there were general issues with them that we didn't always have the engineering resources to fix in a timely manner.

So with the additional volunteer resources that OpenDarwin.org brings to the table, they've been able to do some very high quality releases of Darwin for both the x86 and PowerPC. So we're very happy to see that. Another thing that they've been doing is providing RPMs for all of the components.

So you now have an RPM database installed that you can query to see where various components belong or where they came from. Obviously updates and whatnot are possible in the future. They're not doing that yet, but that's certainly an option. They're doing that in conjunction now with real package management behind the operating system and they're providing SRPMs which correspond directly to what they use to build the binary bits.

The Darwin Ports Project, which you'll also hear quite a bit more about in this chain of presentations, has been doing what it can to bring more third-party software to the platform. And they have a WebDAV mountable packages collection already at packages.opendarwin.org. So you can simply connect to that in the finder and double-click on one of the packages there and poof. Well, I don't mean that the way it sounds.

and many more. I mean, bingo. That's the word. So we've also changed the way we do open source releases. In the past, what we did was we essentially just pushed out copies of our live CVS repository at periodic intervals, and we had some stuff that was just live, you know, on a minute-to-minute basis.

And that was cool from the perspective of being able to see sort of the work in progress, but what it really didn't do was give you any directly correspondent bits to Mac OS X or Darwin, e.g., you didn't know that what you were looking at in CVS was what you were actually running, nor were those bits necessarily compilable at any given time because you were looking at top of tree. There might be works in progress.

There were obviously synchronization issues between different projects. One might be n steps ahead of another, but there's interdependencies because someone hasn't checked that stuff in yet. So we looked at that, and what we started doing instead is breaking our releases into what we call on-cycle and off-cycle, which is on-cycle releases are snapshots of the exact sources that we use to build the product.

So now when you get an on-cycle snapshot, you know it corresponds to a given release of Mac OS X or a given software update of Mac OS X, and they're synchronized together because we didn't have the tag information exported before that would have let you sort of read through the data. So we're able to sort of recreate that state of affairs for yourself. And some stuff is still done off-cycle.

Darwin streaming server, rendezvous, GDB, GCC, various GPL projects, you can still get the CVS top of tree for that. So we're not doing it for absolutely everything, but for the majority of the bits, we're trying to move to an on-cycle model. The source is now available via web DAV as well as CVS, so you can mount the appropriate volume and just drag the sources around. And we're continuously adding. So we're continuously adding. We're continuously adding to what we've previously released as open source. There's a lot of new open source initiatives at Apple.

Some of those. You've probably heard the announcements about WebCor. So the Safari folks have been working very closely with the KHTML team, and you'll hear more about that in this presentation, and the JavaScript stuff as well. Of course, there's also the X11 product now and the SDK. And we've been working all over the map in the third-party software and FreeBSD areas to update components of Mac OS X.

We have a new TCL, new Python, new Perl, new Samba. We've synced up LibC with FreeBSD 5.0 to bring in all the WCharty support and thread safety. So there's too many projects to mention that we've synchronized for Panther. So coming up next, we'll have someone from the Open Darwin project talk a little bit more about Open Darwin and Darwin ports. So let me introduce him now. Kevin Van Vechten of the Open Darwin project and recently of Apple.

I'm here to talk a little bit about the Open Darwin project. Open Darwin, as was mentioned, was started about a year ago. And what it is, is a community supported site outside of Apple. It's hosted by the Internet Software Consortium. Neither the ISC nor Apple exercise editorial control over Open Darwin.

So what that means is Open Darwin is free to explore technologies that maybe Apple doesn't feel is very high priority, but the developer community as a whole would like to see incorporated in Darwin. And once it's working there, we can advocate within Apple incorporating those changes into a future Mac OS X release. Open Darwin provides support for Darwin users. It provides mailing lists, how-to articles, documentation.

It provides a lot of information for using various Darwin commands, which of course are also applicable to Mac OS X. And most importantly, Open Darwin provides resources for developers. We provide the same mailing lists and documentation for information relevant to porting third-party open source Unix software to Darwin. And just kind of being a central point for information about Darwin development. Which of course directly applies to Open Darwin. And that's why we're so excited to be here today. And we're excited to be here today to talk about the Mac OS X, because a lot of key Mac OS X technologies like I/O Kit and Core Foundation are also part of Darwin.

So one of our primary goals in OpenDarwin is to stay synchronized with Mac OS X. We recognize there's a much larger developer community around Mac OS X than there is focused on pure Darwin. So as much as possible, we want to make it easy to take individual components of the Darwin operating system from OpenDarwin. You could compile them on your own and substitute a piece of Mac OS X with the custom component.

As part of that, we provide binary releases of Darwin and components of Darwin. So if you're interested in playing with a particular version, there's a place where you can go. It would be pre-built. You could download it, install from a CD. We also are working to provide an easy build system for Darwin so that you can look at any particular library, command, build it quickly and easily, modify it a little bit, rebuild it again, install it on your system, and use that for debugging, for development. And also, importantly, is OpenDarwin's a staging area for external development.

So, for example, in our current OpenDarwin sources, we have some of OpenBSD's sys trace work as an experiment for dealing with access control on various sys calls. We also have FreeBSD commands brought over from the FreeBSD project, integrated into OpenDarwin, and we've also got some of the open source projects that we've tested there, and then they were able to bring some of those in as part of Panther to keep us up to speed and keep us synchronized with the other open source projects out there.

So OpenDarwin focuses a lot on open collaboration for developing software that pertains to Darwin and, of course, Mac OS X as a whole. We host projects relevant to Darwin. For example, KDE Darwin is currently hosted there. It's one of our larger projects in terms of code base. DarwinPorts, as mentioned, is another project hosted at OpenDarwin, which is one of our more active projects.

We provide the infrastructure so that people can create projects and allow developers from the community to sign up, get access to CVS. And we're also working to have a mirrored version of a lot of the Apple projects, say Streaming Server or HeaderDoc. Eventually, we want to see some of those in a repository at OpenDarwin. So third-party and community contributions can be put into CVS there, tested, integrated, and then advocated back at Apple. So that's a potential enhancement or bug fix or whatever.

So the Darwin Ports project, being one of the most active projects at OpenDarwin, is a project designed to port open source software to Darwin. Its main focus is the easy installation, removal, and upgrading of software from source or binaries. The binary support is still a work in progress.

One of the reasons why I'm mentioning it here in OpenDarwin is there's a fair chance that we'll be using Darwin Ports as means of building the individual components of the underlying Darwin operating system at OpenDarwin, so that there would be a port for each, not only third party and open source Unix software, but also for each of the components of Darwin.

So it would be as easy as saying, you know, build and install a core foundation on a single command line, and it could do that for you. There's also a Cocoa user interface to Darwin Ports. It lets you browse through all the available software that currently has a port file representation. You can choose what you want to build, click on it, it'll build, install on your system.

So the most important thing I want to mention today is that OpenDarwin really is a third party independent project and it does need your help to be successful. And if everybody joins the mailing list and discuss any Darwin technical issues they have, it can really be a good central resource for development for Mac OS X, for Darwin, for porting Unix applications.

Also, we have a Bugzilla database at OpenDarwin, so there's a good opportunity to report any bugs with Darwin, with any libraries or commands there at OpenDarwin, as well as submitting a patch or at least making a reference to saying, well, this isn't a problem in NetBSD or this isn't a problem in FreeBSD. And then somebody at OpenDarwin can take a look at that, figure out what needs to change, and we can incorporate that back into Mac OS X. There's a couple mailing lists at OpenDarwin.

If you're interested in proposing projects relevant to Darwin or discussing new features or enhancements, that would be appropriate for the discuss list at OpenDarwin. If you're interested in submitting patches, code, documentation, that is appropriate for the hackers list at OpenDarwin. and there's a couple interesting other sections pertaining to open source and Darwin, QuickTime Streaming Server, Rendezvous, GCC, Unix sysadmin tools. And up next is Don Melton and he'll be talking a bit about Safari.

Hi, I'm Don Melton. I'm the Internet Technologies Manager at Apple Computer, and I'm here to talk to you today about Safari and open source. And I'll give you a little roadmap to some other sessions here at the conference.

Why is Safari so successful? I mean, because people are not only downloading it, I think 5 million so far, something like that, they're actually also using it. Some of them are making it their default web browser. I think of three reasons why it's so popular. First off, innovative features. It's got a superior user experience. This is a full featured web browser. People take it seriously. It can do things for you.

Secondly, solid quality. Real world compatibility with the web. By that I mean pages look the way you expect, and they look the way web designers expect them to look too, especially if they write to web standards, but hey, even if they don't. But most importantly, impressive performance. It's the fastest browser on Mac OS X. We beat everybody not only on the standard benchmarks, but we also beat them in just real world use, loading pages, scrolling, reading. Resizing, launching especially. 1.0 is faster.

And now the underlying technology within Safari is built right into Mac OS X. And it's this underlying technology that I want to talk a little bit about today because it's based on open standards. Firstly, it's based on W3C standards like HTML4, XML, CSS, DOM, so on and so forth. But more importantly, it's based on open source. And that's open source from the KDE project.

The KDE project, as many of you might know, is an open source desktop available on Linux and other Unix platforms. It has all sorts of applications and utilities and libraries. And one of the big applications is the Conqueror web browser. And the Conqueror web browser uses two libraries. Thank you.

Two libraries, KHTML and KJS. And we're using those same libraries within Safari. First, we're using it in a framework called WebCore, which is just an adapter built on KHTML from KDE. It uses most of the KHTML sources, about 95% of them. And it has glue code to the rest of Mac OS X, which has also been open sourced.

We also use JavaScript Core, which is just a simple wrapper around the KJS JavaScript interpreter, also from KDE. But that's not all. Safari also contains other open source components in WebCor and in JavaScript Core, such as the XPAT XML parser, the PCRE regular expression library, and even, shock, portions of Mozilla code. I mean, a lot of people are actually surprised at that when they go perusing through WebCor.

So why open source? It's all about the technology. It's not just that it's a good development model, but for us, it was a technology decision. KHTML and KGS are just tremendous technologies. I'd like to tip my hat to KDE developers for their fine work for that. And let me just go into detail as exactly why. One, it's small.

KHTML and KGS together are about 140,000 lines of code. That's almost an order of magnitude smaller than some other projects and web browsers. and it's fast because if you have less source code, you've got less binary code. Less binary code means you execute things faster. It's also designed for speed. It's really designed well.

and it's easy to modify. This is a fun source base to hack. It's just a hoot to get in there and mess around with it. It's easy to understand. There's not layers and layers of abstraction to figure out. It's very, very straightforward. And we've tried to maintain that with the rest of our development.

Okay, what are we doing with the community? First off, we're working with the KDE team. These are great folks. We're on mailing lists with them. We've had at least one transatlantic phone conference call with the KDE team, KHML and KJS developers. And Hari Porten, the lead on KJS, has actually been out to the Cupertino campus to visit with us. So they're great folks.

We're giving back all of our bug fixes and enhancements in WebCor and JavaScriptCor. And we also send patches on the mailing list to the development team at KDE. We're also taking in patches and other changes from the community. In fact, just a few weeks before Safari 1.0 went out, David Heitz snuck in another little feature from the Tip a Tree KDE.

and we're sharing ideas and plans for the future. When we work on something and we know we're gonna be down in section of code base and we might be pulling it apart, heads up guys, we're gonna be redoing the plumbing on this and the KDE folks have done the same thing with us.

When Lars Noll, who's the lead on KHTML said, "I'm gonna be mucking with the CSS parser, stay out of that." We went, "Great, just tell us when it lands so we can take it." And that's one of the things that went into our beta too. We're also planning, now that we've survived our 1.0 release, and boy am I glad that we did that, we're going to have another one of those Transatlantic Conference calls with the folks there.

But you can contribute too. And that's the other thing that I wanted to talk about today. You can contribute not only to our projects, WebCor and JavaScriptCor, but you can also contribute to KHTML and KJS because, hey, it's the same code. I mean, it's just fine with us and we'll get it from tip of tree and we'll swap patches back and forth.

We would love to get bug fixes, enhancements, and even other ideas from the community. If you go to the Apple open source site, you can find the mailing list that you can join. You can get the tar balls of the current versions of WebCor and JavaScriptCor and jump in.

We really look forward to that. Now I'd like to point out a couple of other sessions here at the conference. I'd like to say I'll be here all week. Come at 2 o'clock to the Safari overview. It's upstairs in the Presidio room. And I'll be rambling on there for about an hour.

And then tomorrow, Safari technology and web standards, if you care about web standards. Darren Adler will go into detail for it. We're going to be covering some of the new APIs and foundation on Thursday. There's an overview of networking that might be useful for some of you. And the marvelous web kit on Friday. And some lower level plumbing that folks might be interested. CF network in depth also on Friday. Thanks so much. And I'd like to call Richard Blanchard to the stage. And talk about it. printing.

Hello. I'm Richard Blanchard. I'm the Apple engineering manager for printing. And today I'm going to give you a little bit of insight in what we've been doing with our printing projects inside of Darwin. A year ago in this exact session, I was incredibly pleased and excited to announce that we were including CUPS, Common Unix Printing System, into Darwin and into Mac OS X. And that's the basis of our Jaguar printing system and our Panther printing system. Over the last year, I spent a lot of time rolling important fixes from the ongoing CUPS mainline development. We used CUPS 1.1.15. CUPS since then has moved on to .16, .17, .18.

We've taken bug fixes from those changes and security fixes and rolled them back onto our .15 base. That's kept us pretty busy. Over that year, I've been reading some postings from people who were concerned, maybe was the right word, that we were maybe stagnating. Darwin and Mac OS X was using this .15 base. Meanwhile, CUPS was running ahead and was all the way up to .18. That's just not the case. As I said, we've been moving these bug fixes back. But the reason I really bring that up is not because I'm really oversensitive to these posts.

But instead, it's because there's an important point there. One of the reasons we went to CUPS to an open source printing system was for transparency. It was so the developers could look, see what we were doing, give us feedback before we actually made a major release. And in that same vein, our CUPS repository, our CVS repository is part of Darwin, is live every day. So you can go on to Darwin and see what we've done any given day. And we've had our Panther CUPS development, which is based on 1.19, up there for some time.

So again, for Panther we're using 1.1.19. There are some important changes in there, important fixes, important features. There are some bindings for new languages, so there are Java bindings now. That'll be in Panther. PHP and Perl bindings, so you can actually make CUPS calls, create printers, and print directly without going through the print system from those languages.

There's fax support, which is important if you saw the keynote last night or yesterday morning. IPP collections, which allows us to do some better error handling, and improved PPD support. The PPD parser in 1.1.19 is much tighter than it was in earlier versions. It'll flag PPDs that are bad much more easily or much more clearly. And it also allows access to most of the PPD keywords, whereas the earlier PPD libraries did not.

GIMP Print has been out there, has been used by a lot of our users, as has HPI.js. This is actually one of the most exciting things about using CUPS, is that the world of open source printer drivers is available to our users and to our developers. And this has really been great over the years, supporting some older printers that maybe the vendors haven't gotten around to supporting.

As you can see, GIMP Print supports over 500 printers from most of the major printer vendors. HPI.js supports a couple hundred HP printer models. That's a lot of legacy printer support, and it's been great for us. There's also been some important support from some of our Linux cousins.

If you go to linuxprinting.org, you'll see some great Mac OS X printing pages supporting these two packages. So I encourage you to go look at those. This wasn't stolen for the keynote, and I'm very happy. I get to announce today that GIMP Print's actually going to be part of Darwin and Panther. So we'll have those drivers in there by default. Ready? There you go.

But there's more. As you saw the keynote, there's also Fax in Panther. And following our printing tradition, what we wanted to do is take an open source core, put that into Darwin, and then build on top of it in our commercial OS. So we used eFax. If anybody knows the Fax landscape out there, there's really two different open source projects.

There's eFax, which is very small. It's not an incredibly active project. And there's HiLiFax, which will do everything you'd ever want in faxing, and it's a lot larger. We actually went with a smaller project. It seemed to fit our goals more cleanly. So we've got eFax. It's in the Darwin repository right now, and it'll be in Panther, and it's available for you.

I'll be talking Thursday, much longer, about printing in Mac OS X Panther, but also going over some of these Darwin printing projects. So again, the most important message I have for you today is we have three projects now that are tied to printing that are all in Darwin. We have CUPS, the print server. We have GIMP Print, a set of printer drivers. And we have eFax for our fax port. All three of those projects are live every day. I encourage you to, if you're interested in any of those, track our changes every day.

Send us mail. Let us know, hey, this change was wrong. Hey, we should pick up this other change that was coming from another project. We do this so we can be incredibly transparent to you so you know what we're doing for our OSes before we have to release the GM version. So anything you do to help us would be much appreciated. So I'm going to introduce Torrey Lyons. He's going to come up here and talk about XFree86.

So XFree86 has a fairly long history on Mac OS X comparatively, at least as far as this operating system goes. The initial Darwin support was in the late 2000 with XFree86 4.0.2. In this release, you had to shut down core graphics. XFree86 would talk through the IOCAD directly to the hardware. Then in subsequent releases, we added the ability to run in parallel with Aqua, where you could have two separate virtual screens and switch back and forth.

And then we added a rootless mode in early 2002, and that's culminated in the 4.3 release, which gives us faster 2D and hardware-accelerated OpenGL. Now, of course, the thing that's missing from here, or is yet to come, is the 1.0 release of Apple's X11.app, which is a very exciting thing in this area. And as most of you probably know, that's based on the XFree86 code base. At least their current beta is based on XFree86 4.0 and Apple's X11.app.

So, what are we planning to do in the XFree86 project? Of course, the most important thing for us is to get the lot of good changes that Apple's made in releasing X11 merged into the XFree86 code base. There's a win-win situation if we can get Apple's X11.app and the XFree86 open source release tightly synchronized. And we're working hard on that.

And what really makes that possible is this XPlugin API, which allows open source developers to really write high-performance X servers. The problem we had sort of at the end of the 4.3 development is that essentially what we're trying to do is we're trying to write an XWindow server on top of another Windows server, which is Core Graphics. And there weren't existing public APIs in Mac OS X that allowed us low enough level access to get the performance we really needed.

So, in discussions with Apple, what really emerged was that actually Core Graphics has all the capability we need, but that there aren't -- the APIs we needed aren't private APIs that are hidden and not exposed and therefore not suitable for open source code. So, what XPlugin is, is it's a library that is exactly what you need to write an X server on Mac OS X and no more. So, it's fairly easy for us to write an X server on Mac OS X and no more. So, it's fairly easy for Apple to maintain as they go forward.

And it also allows open source developers sort of a green light to go ahead and write very high-performance X servers on Mac OS X. And this is really the big news as far as my part of the talk is that -- Apple's X11 we would think of as the first implementation of an X server using this X plugin API. And actually, if you check it out, you can check out their beta 3 source code. You'll see it's XFree86 with acceleration features added in, and they're just using OpenGeo, Core Graphics, and this X plugin API.

So we'd also, in addition to making things go faster, we'd also like to make them better. So we're working on adding multiple visuals of various classes and depths. The common problem here is that you want to display an 8-bit pseudocolor visual and a 24-bit true color display. And actually, beta 3 has a way of doing this.

It has some problems. We think there's a slightly more general implementation that we're going to put in. And we also, of course, moving forward, want to support new XFree86 standards. Of course, the key reason to have a version of X11 running on Mac OS X is it's an essential compatibility environment for scientific and Unix developers and users.

And compatibility environment is only so good as you stay compatible with the latest stuff coming out in the rest of the community. So I've listed some things here that we're working on. R&R, XCursor, ability to add cursors with alpha channels that are coming out on other platforms in the XFree86 project. And we'll be including those in our Mac OS X support as well.

The last thing we'd like to do, now that the picture on Mac OS X for X server is getting pretty robust, we'd like to add, or at least turn our eyes back to I/O Kit mode. And the top of the tree already has some improvement with this. This is of interest to those of you who run Open Darwin or Pure Darwin without the rest of the Mac OS X goodness.

We'd like to get I/O Kit closer to the kind of performance you'd expect in other open source operating systems. And what's available, if you build from the top of the tree today, I suggest you do if you're running Pure Darwin, you'll notice that the drawing performance is much better. It uses shadow FB instead of trying to draw directly to the frame buffer.

And that's much better than what you see in the 4.3 branch. So of course we always need help. And if you're interested in helping, I'd suggest you stop by [email protected]. That's the sort of central mailing list for xFree86 development. And these are some talks that would be useful to understand a little bit the environment that we're working in here to implement an X server. So next we're going to have Ed Peterlin come up and talk about OpenOffice.

Today, it's really a lot of fun. I was here a year ago saying, we got a compiling, we need your help. Yesterday, we went gold master. OpenOffice.org 1.0 is here. We support Mac OS X and we finally refactored everything to support Darwin PowerPC as well. So now you have a full office productivity suite on Darwin. Truly amazing. It runs on Mac OS X with X11 graphics and I'm actually pleased to say it does run on Panther with the X11 on the second CD.

Take the installer, it runs. It just runs. And yesterday, another thing people may not be aware of, we released simultaneously in over 20 languages at the same time. Italian, Greek, French, Dutch. All of these users now have localized versions of OpenOffice.org in their language. I was here one year ago as one person. Since then, I got another core developer, a volunteer, of course. We all have real jobs and real lives.

Two people, and we moved... Two people, never more than six, moved seven and a half million lines of source code in only a year. This is an amazing operating system and this would not be possible without the synergy of open source on this operating system. You know what? It really is a thing of beauty. This is the X11 version. Full anti-aliasing. You have access to all of your OS X fonts.

It's really nice, and you can go get it today. We're doing CDs here because she's got a little around the edges. Just a little more than the other platforms, about 100 megs more than the other platforms. But since we've given out CDs yesterday, approximately 5% of everyone at this conference now has it on CD. Okay. Yes, you can see us in the exhibitors booth. A lot of heavy drinking went into the CDs, so appreciate them.

But you know what? This proves one thing. We're a great community and we're a community of doers. But you know what? We don't need doers. We need dreamers. We're not stopping here. This is the beginning. This is the beginning. You know what? Guys, the hard stuff is done. It all works. We've got to move forward. We've got to plow forward.

OpenOffice.org 1.1 is going live on other platforms with some amazing features. Improved scriptability support for writing full infrastructures and middleware on this as a cross-platform delivery solution. Mind-blowing. You can run your same middleware on OS X, Windows, you can throw it back on a Solaris box if you need, or if you don't have a G5 or can't afford it like me because I'm poor. And also vertical and right-to-left languages. We're beginning to get CJK support, Arabic, doing BIDI. But you know what? That's not enough.

So why don't we replace X11? We're going to use core graphics and quarts. And we're going to get it running right on OS X. We're going to have tighter Mac OS X integration. We have visions of integrating with services so we can start exchanging everything with mail and other applications. Finally, getting the clipboard working. and of course, Aqua User Interface, the one that everyone wants.

That's not a mock-up. This is a prototype. This has been out there and available for six months. Go out, get it, look at it. Help us try and find out how we can do this properly and do it right. Now's the time for you to jump in. All you people who weren't core hackers before, who were afraid to touch make files, now you can start.

And today I'm also pretty pleased to announce, if you're not a core graphics developer, if you're not a Node 10 developer, there are Java guys out there too. We have a full Java prototype project that is now up using Java 2D only for the drawing. 99% C++, Java 2D for the drawing. And the amazing thing, it's only a week old, but it supports Japanese text input on Mac OS X in Unicode. That's phenomenal.

Basically, come. Help us find out where we're going to go. This is everyone's thing. You can actually put part of you into it. We need UI design experts trying to figure out how to make this right for a Mac user. We need graphic artists who can actually come and draw all new icons for us, get the interface working.

Cocoa developers, help us find out how we can move this to Interface Builder and all these other great Apple technologies. We need courageous testers who aren't afraid and don't get upset if we happen to just lose that data file. And also, we need evangelists. Go out and just tell people about it. Be like, look, this exists.

You can use all of your... Office documents, won't say the word, all of your office documents right now for free. It's amazing. Stop by mac.openoffice.org, take a look today, and help us out as you can. Thank you very much. And now I'd like, it's my pleasure to introduce Lane Roath, who's going to tell us about OpenPlay.

It's a cross-platform project. It's standards-based. It currently is running on Mac OS X. It has a classic build as well. It runs under Windows and Linux. And the Mac OS X build has both a CFM-based and a Mac OS-based build. It's a modular build, meaning that the underlying protocols, like TCP and Apple Talk, are plug-in modules. There's the flexibility to add new protocols via that modularity. And in fact, this year, that flexibility has been used. And the use has been to add Rendezvous support.

It's got a large adoption. A lot of titles are using it, a lot more titles coming out. Most of these titles happen to be games because of the NetSprocket API, and that's what people know. But there's no reason that it is a games-only API. You can use it for any kind of quick networking that you'd like.

It has a few simple layers. Your application can talk to any of the layers directly. There's the game interface, which is the NetSprocket API. It's very easy to use. It handles multiple users. You can group users. All that high level stuff is very easy to do via that protocol. There's the protocol module, which is the former OpenPlay, and it deals directly with the abstraction of the modules that you deal with, TCP, AppleTalk, and you can talk to those modules directly as well, whichever you would like.

The game interface, like I said, provides the easiest way to add networking to your game or other application. It has player management, game management, packet management, and again, it runs on all the different platforms. The protocol interface is fairly low level. It's much closer to like a sockets based protocol. It has the protocol agnostic design so that you can use one API and you can talk over Apple Talk, TCP IP, or Rendezvous. It has the IP module for all platforms. It has Apple Talk for Mac OS and Mac OS X. And it has Rendezvous for Mac OS X.

The next step, of course, is the newest plug-in module that was developed by Freeverse Software and committed back to the community for everybody to use. So that should give you an idea of how easy it is to add a new networking API if you happen to have the need. If you want to know more about OpenPlay and everything that's going on with that, there's not an OpenPlay specific session this year, but you can learn more about the general OS X networking, the higher level CF networking, and then just the general internet technologies that are available.