All right, ladies and gentlemen, thank you all for coming today. Good to see you up bright and early in the morning. I'm up awake. We are going to be talking about Bonjour, and we're going to be talking about four things today. We'll start off with a recap, because I'm sure most of you in the audience know what Bonjour is, but not all of you will know the details of how it works.

So we'll start with that. Then I'm going to tell you about what's new in Leopard and other news. I'll show a few demos. I know you all expect by now to see a few cool demo toys, and I won't be disappointing you. And then I'm finally going to run through setting up wide very bonjour, because that's the question we get a lot.

So, the recap. Bonjour is about using TCP/IP and Ethernet and Airport 802.11 Wireless, but with the ease of use that we expect of USB. Ethernet cables can be 100 meters long instead of 5 meters with USB. You can connect hundreds or thousands of devices to Ethernet. The speeds go up to gigabit. Clearly, there are big benefits there. By solving the ease of use, we make that possible to use Ethernet really as a viable substitute for products that today would use USB or FireWire or Bluetooth or IRDA.

So why Bonjour? We want to make network products that are a joy to use, not a frustration. And I have a real story to tell you today. A friend of mine bought a USB printer, wanted to put it on the network because he has more than one computer at home, and he was in Fry's Electronics, and he saw the Apple Airport Express base station was there for $130, but next to it was another company's print server for $80. And he told me afterwards he felt really foolish. He said he should know better. He knows me. He knows about Bonjour. But he bought the $80 one.

I'm not going to name the company. Don't want to be picking on anybody in particular here. But it took him five hours to get this thing set up. And he went through-- well, for a start, it had a wizard that only runs on Windows. So he runs his Windows machine, and he goes through all the steps. And first thing it does is destroy all of his network settings and change them to something else. And then he goes through all the steps, and the screen says, failed. Maybe you have a firewall.

So he thinks, well, I do have a firewall. I don't see why it would block outgoing connections, but maybe. Maybe. So he disables the firewall and does the whole thing again. And it still says failed. And this guy's a smart guy. His time is worth more than $10 an hour. So why did he buy this product? And I think partly it's because we're all optimists.

To use computer products today, you really have to be an optimist. You have to be expecting things to go well. And at no point in that setup wizard did it tell him-- they should have signs, like when you're at Disneyland, that says, only five more hours to go from this point.

But of course, they don't even know that, because they don't know how many dead ends and failures and reboots and restarts and uninstalls and reinstalls you're going to go through before you get it to work. So after spending five hours getting it set up, he then wanted to print from his Mac.

And in the 300-page manual, there was nothing about the Mac, but he went on the web and he found this 11-page addendum for how to set it up with the Mac. And it just goes on, page after page, little circles and arrows, and click the plus button, and type in.

L1 for the name, and L1 for the queue, and L1 for the location, and on and on and on. And then you have to click Installable Options. And then you have to go and edit the name and location you just set up. The location has to be the IP address with IP underscore at the start of it. You have to give it a manual IP address. The device doesn't do DHCP, because if it did DHCP, it would get a random address each time.

And then how would you know what address to print to? So the user of this has got to understand IP addresses and subnets. And they've got to know how to assign an address that's on their subnet, but not one that's going to be assigned by their DHCP server. This is just horrible. This company is torturing their customers.

They won't put up with it forever. So when he called me about 11 o'clock and gave me this tale of woe, I decided, out of honest scientific curiosity, to go and see what the Apple experience would be. I took my AirPort Express, and we went around to his house, plugged it in. I went file print in Safari, and So no printer selected. I joined the right airport network, and there's the printer. Total time from plugging in to the paper coming out, 90 seconds.

He said, well, what about Windows? We downloaded Bonjour for Windows. No restart required. Ran the printer setup wizard. Found the printer. Total time from download to paper coming out of the printer-- 90 seconds. So it took him three minutes to get this thing working on Mac and Windows. So that's the lesson for all of you here making hardware products and software products that do networking. The status quo may have been acceptable to computer geeks in the past, but it is a brick wall. It's a barrier to growing this market to a larger audience.

So this is the goal. We all know what we want. And there are products out there today that demonstrate that. How do you achieve this in your network products? There are three technologies, and they're intentionally very, very simple. I won't go into them in great detail, because we've covered that in previous WWDC presentations. But the summary is, link local addressing gets your device an address, even if there isn't a DHCP server, or it's misconfigured or defective.

Multicast DNS lets you look at names when there isn't a DNS server, or it's misconfigured. Or maybe there is a DNS server, but you as the user don't have access to actually be editing the configuration and putting names into that DNS. And then the third layer is service discovery, where you don't even have to know the name of the device in advance, because you can browse the network and say, I want to print. Who out there can give me that service? From a software perspective, if you're writing applications, if you are offering a service on the network, you use the Bonjour operation register--DNS service, register service--and that advertises your service on the network so that clients can find it.

On the client side, you have two operations. You browse to get the list of services, and when the user picks one, you resolve to translate that name service into its current IP address and port number. In a world of DHCP and self-assigned link local addresses, addresses can change, and that's why resolve is a separate step, because the name stays the same, but the address may change from day to day.

So we have two flavors of Bonjour. We have the LinkLocal Bonjour and the WideArea Bonjour. What characterizes the LinkLocal Bonjour is that it's absolutely bulletproof. There is nothing to configure, so it can't go wrong. It's your safety net. When all of the networking is broken, Bonjour is there.

And if your device is configured through a web page, it's the bootstrap that lets the user get to it to configure it to fix whatever the problem is. WideArea Bonjour uses exactly the same register, browse, resolve APIs that you use with LinkLocal. But by using a DNS server as a central aggregation point, it scales beyond the physical link to quite literally the entire planet.

Last year when I was in London and I was collaborating on some documents with Mark Krockmull, we used SubEtherEdit, the multi-user document editor. And we were 5,000 miles apart, but our shared documents appeared in each other's Bonjour list because it was using WideArea Bonjour. And that was the standard SubEtherEdit unmodified inheriting the benefits of WideArea Bonjour through the same APIs.

By now, Bonjour is something that's readily available. It's not something off in the future the way it was when we first announced it four years ago. It's been on Mac OS for several releases. Bonjour for Windows is on its fourth release. There are Apple and other open source third-party implementations for the Unix platforms. There are new implementations for little embedded devices. And you can get Apple source code from Darwin and use that for whatever you want.

In terms of Apple software, if it does networking, it uses Bonjour. And it has become so much woven into the Apple DNA now that nobody would consider making a networking product that didn't use Bonjour. When somebody talks about networking, they don't have to say TCP and IP and ARP and Ethernet, and they don't have to say Bonjour either.

Lots and lots of third-party products. I haven't tried to list all of them, but just a selection of some of my favorites. Toast will share your DVD burner over the network. So from any machine, you can burn to any other machine's DVD burner. SubEtherEdit-- really, really excellent multi-user document editor.

And the real cleverness there is how they solved user interface issues of having multiple people editing simultaneously so that as I'm typing, you can be correcting my spelling mistakes. Bonjour is really just a tiny, tiny aspect of that product. But in many ways, it's kind of the lubricant in the machinery without which it would be much harder to make the wheels turn.

When it comes to hardware, obviously, desktop Macs, laptop Macs, Apple base stations, anything Apple does that has TCP/IP networking does Bonjour. And if Apple brings out future products that do networking, you can be sure they'll do Bonjour as well. When it comes to third-party products, every printer from every major printer manufacturer, if it does networking, it does Bonjour.

We have network cameras. We have home gateways. I'm going to show you one today. all of these products you've probably seen yourself If you are advertising or discovering a network protocol, you should register that type at dnssd.org to make sure that it's unique and no one else uses it. And this is just a sample. Last time I looked, there were over 300 service types in that list.

Some of them are very widely used, like HTTP is implemented and advertised by lots of devices that have web servers in them. Some of them are very specific. A multiplayer game where your program is the only implementation of that game, you have a service type there that's exclusive to you and only used by your client.

So here's an example. There's an open source software voice over IP PBX program called Asterisk, which is very popular on Linux and OS X. And the latest version of Asterisk advertises its settings using Bonjour. And there's a tool I'm showing you here called John's Phone Tool, which is a dialer that runs on the Mac. And this is the original screen where you set it up. You have to put in the IP address and the core idea and the context. And I don't know what any of that stuff means. Well, in the latest version, there's a tab, Automatic Configuration.

When you click that, it just all goes away. You click on the menu. It shows you the list of available Asterisk servers on the network. And from the text record advertised by those servers, it auto-configures all the necessary parameters. So all you need is a username, password, pick the server, and you're connected. Now, on a desktop machine with a keyboard and a mouse, configuring complicated stuff is a pain, but it's not impossible.

This thing looks like a cell phone, but it's actually not a cell phone. It's a 802.11 Wi-Fi phone. And this uses the standard voice over IP protocols that asterisk support. And configuring IP addresses and subnet masks and all that nonsense on this little keyboard is next to impossible.

So Hitachi are going to be shipping the next model of this phone with Bonjour. And there's a lot of demand from their resellers in Europe, actually, for this one, the WIP5000, that they're sick of the pain of setting it up. So we may even see a firmware update to add Bonjour to this phone.

So now some reminders for developers. Common mistakes we see. Link local addressing is really important. Time and time again, we hear people say, we love Bonjour, we love the discovery, we love the browsing, but our customers will always have a DHCP server. And the problem there is the optimism again. We're assuming everything will go right. And when things don't go right, that's when the customer gets really frustrated, and that's when it's most important that we do everything that we can to help things go smoothly and get them out of that mess.

IPv6 has link local addressing as part of the standard protocol. So if you do v6, you almost certainly have that for free. I realize a lot of hardware devices today don't support IPv6 yet for memory resource constraints. So if you only do v4, then do IPv4 link local addressing.

And it really isn't as hard, I think, as people imagine. And here is one example of how you might do just a quick and dirty link local addressing, good enough to be a safety net to get the device on the network. Take your standard DHCP client code, but make it time out after five seconds.

So it says discover, discover, discover, no answer from the server. Well, it pretends there was an answer. You just build a fake ACK packet in memory, put a random address in the packet, and pass it back up to the stack and say, yes, I got an address from the server.

And the high levels of the stack will then configure that address. If it's a proper implementation of DHCP, it will check using ARP to make sure that address is not in use. And if it finds it's in use, it will send a DHCP decline to the server saying, bad address, give me a different one.

Well, for link local address, you can make the decline a no-op because you have no server to send it to. You just go back around the loop and try again. Discover, discover, discover, time out, pick a new random address. And developers sometimes ask how long this will take. They're worried it might take a long time to get an address.

But remember, there are 65,000 link local addresses, and typically two devices on the network. So the likelihood of you having to try even more than once to get an address is pretty small. And if the alternative is this or not working at all, clearly this is definitely a superior solution and almost no work.

So please, if you're making a product, don't skip the link local addressing. Thank you. Another solution you can use, which is used by some devices like this Axis camera, is They configure two addresses. And if you're using something like embedded Linux, this is very, very easy to do.

In their manual--because historically they had a fixed factory default IP address, and the manual tells people to use that, and it tells people to reconfigure their PC, very much like my print server story, to be on the right subnet with the factory default and blah, blah, blah. And they didn't want to have to reprint the manual in the short term, so they give it two addresses.

So it has a link local address, which you can discover with Bonjour, and if you're doing it the old manual way, then the other address is there as well. So you don't have to have a big flag day and uproot everything and change all your documentation. It's possible to add this while supporting the old way at the same time.

Another plea to all your hardware developers out there: use Power over Ethernet. When Power over Ethernet first came out, it cost thousands of dollars for a hub. This is the Netgear hub for under $99 now if you shop around. It's eight ports, four are powered and four are not, which makes perfect sense for the home user, because you don't need power to your Mac, you don't need power to your cable modem or your DSL modem, so four powered ports is ideal for running a few things like an airport base station, a PoE camera, something like that.

Netgear does a 16-port version with eight powered for $200, 24 ports and 12 powered for $300. So Power over Ethernet is really now affordable for consumers, and it erases really that last-- There's a reason to prefer USB, because USB gives you ease of use and power. And now with Bonjour and Power over Ethernet, Ethernet gives you ease of use and power. So we can now start making network products that are as convenient and easy to use as last year's USB products.

When you've made your product, run the conformance test. That's a great tool for finding common coding mistakes, which are corner cases you may not have thought to test, but they're corner cases customers might run into. So it's good to test those and fix them. After you've done that, for no charge, send in the results of the conformance test, and you can license the Bonjour logo to go on the box.

Stuart Cheshire And that badge on your box is kind of--we will never see product makers put a sticker on the box that says, "We'll waste five hours of your time." But this logo is the "We'll not waste five hours of your time" badge. So we encourage you to put that on your products so the customers know what they're looking for.

You can also, for no charge, license Bonjour for Windows to put on the CD or for download so that your Windows customers get the benefits of this ease of use as well. Because we understand that when you're doing engineering work to put this in your hardware, the management people often say, "Well, this doesn't benefit the bulk of our customers." Well, with Bonjour, it benefits everybody with Bonjour for Windows.

You can license that for no charge. And when you install that, you get the Bonjour icon in the Internet Explorer toolbar, just like you do in Safari. You click it, you see the same list of discovered web pages. So if you've got a product with an embedded web server as its user interface, advertise it with Bonjour. Ship Bonjour for Windows and Mac and Windows users get the convenience of just discover it, click it, connect, don't care what the IP address is.

If you're making Windows application software using the Bonjour APIs on Windows, contact us and let us know. We are currently talking to some PC vendors about bundling Bonjour for Windows pre-installed on their PCs, because they're tired of the grief their customers go through as well. So if you've got cool software products for Windows that use Bonjour, let us know. And there might be opportunities there for bundling a demo version of your product pre-installed on these Windows PCs.

Right, what's new since we met last? A lot of you won't care a lot about this, but those of you who do care probably care a lot. You will have heard this week that the Multicast DNS Responder, Darwin Project, the Bonjour code is now licensed under Apache 2.0, which fits in a lot better with companies who have products where the rest of the code is licensed under BSD or GPL or Apache. They now don't have to learn a different license and try to work out how it fits in.

We have a new feature, Private DNS. When you're using wide-area DNS, it works like standard DNS today in Tiger, which is DNS is a public database. Ignoring issues like VPN and encryption with standard DNS, anybody can do a query and everybody gets the same answer. And one question we heard from some developers was, "What about privacy?" When I go around the world and dynamically update my host name to different IP addresses, some kind of cyberstalker could be looking at my IP address and see, "Now it's at San Jose Airport.

Now it's at the W Hotel in New York. Now it's in London." So we're adding a feature where only authorized clients can do a DNS query. This is an extension to standard DNS, but if you care about that issue, this is a feature that will be available in Leopard. Yeah.

For those of you who are implementing your own implementations from the specifications, instead of using the Darwin code, we have updated the specifications. These are getting pretty mature now. There aren't major differences from last year, and in fact, I predict by the end of this year, these drafts will be stable enough. There'll really be no more changes to make, and these probably will start getting RFC numbers on them.

Application programming-- when we shipped Bonjour in 10.2, you could program it from C-- there was core foundation, there was code code-- but basically, C APIs. In 10.3 and 10.4, we added Java APIs for the Java programmers. And in the Leopard build that you all got this week, we have two new things. The Java APIs included the standard register-browse-resolve, but what they didn't include was one particular call to register specific individual records. That was in the C API, but not Java. We had requests. We've added that. We also added Ruby language bindings.

And those of you who have used Ruby will know what a powerful language this is. There's an interesting story here about how this came to be. A couple of years ago, I was talking--giving a tutorial at the O'Reilly Open Source Conference in Portland, Oregon, and a couple of Ruby developers were in the tutorial, and they got excited about Bonjour, and we went to the bar afterwards and had a drink, and two hours later, we had working Bonjour APIs for Ruby.

And in fact, their first attempt at it, they kind of hit some brick walls and struggled a bit, and that was when they called me and asked if I'd mind helping them, and of course, I was completely happy to do that. And the mistake they made was they'd failed to understand the asynchronous nature of Bonjour.

And I mention this because this is an important lesson for everybody writing software. It's a very, very common mistake for developers to write code where you start browsing the network, and you wait for 10 seconds, and you show some stupid animation like a flashlight sweeping back and forth.

And then after 10 seconds, you show what you found. And at that instant, the list is already becoming out of date because you're not updating it anymore. And that is just a horrible user interface. Don't do that. All of the Bonjour operations are asynchronous. You do the call, and it returns immediately.

And then as the results are found, your asynchronous callback routine will be called saying, add this printer, add this printer. Oh, remove that one. It's gone away. And your list updates live. Stuart Cheshire So what that means is that you can have the list of services on the screen in typically a tenth of a second, faster than the user can tell.

But if a new printer appears 30 seconds from now, don't make them click a refresh button. It just appears in the list. Printer goes away. It disappears from the list. That's the experience we want. And the Ruby guys said, aha, now we get it. And they quickly redid it. And they came up with this amazingly elegant API. Stuart Cheshire And I want to show a little bit of real code. We had a summer intern working with the NFS group.

And those of you who went to the NFS session will know that they have a new feature called executable maps, where instead of having a static text file listing the NFS service that you want to mount, it will actually execute a script to find the list of servers.

And the manager of that group said to the intern, you think you could do something with Bonjour. And this is not a code snippet. This is actually the entire program to do Bonjour browsing for NFS with executable maps in Leopard. And there's actually two programs here. So this is the first one.

If you run the script with no arguments, then it does a browse call. And you see it says dnssd.browse arguments do result. That thing after the do result looks like the body of a statement in C, like an if or a for loop or something like that. But actually in Ruby, it's not.

That is an argument that's passed to the function. You can pass executable code as an argument. And what that function does is every time it finds a result, it executes that code. And what that code does is print out the result. And the program that's running the script reads from standard out and gets the list of servers.

So that's how you get the list that's dynamically discovered. When you mount one of the servers, it runs a script with an argument. And in this case, the script calls resolve, looks up the address, and returns nfs://hostname:port/path, and you mount the server. So that's the kind of thing you can do with five minutes of Ruby programming using Bonjour. And that is on your WWDC Leopard build that you have. Now, for the final version of Leopard, we're considering some other things. And I'd like to get some feedback from you guys here. Who would like to see Python support for Bonjour? Thank you.

And you're allowed to vote for more than one. What about Pearl? Do we have OK. We're also open to other suggestions. If you have ideas for other languages that you use that you'd like to be able to access Bonjour from, come to the microphones or come and meet us at the Plugfest tonight and let us know.

And remember, this is open source, so you're welcome to write the code yourself and contribute it as well. And in fact, that's what happened with Ruby. We didn't write that code. The Ruby developers wrote that, and now it made it into the Leopard build. Little glimpse of what we're planning to do in the future.

What we have for you today in the WWDC build is a pretty neat feature, and that's IPv4 link local addressing simultaneously on all interfaces. I've said before that I'm a big fan of v6, and I encourage you to do v6, but we accept that today's reality is that a lot of devices, a lot of hardware devices, don't yet do v6.

And one of the limitations of v4 is if you have Ethernet, an AirPort, an IP over FireWire, in Tiger, only the first one in the list gets a link local address. So you plug in a FireWire cable, sure, you've got IP over FireWire, but you don't have an address on that cable. You only have a v6 address. So in Leopard, we fixed that. We actually are able to configure link local addresses simultaneously on all interfaces that need them.

And when you connect to a link local address, it will actually ARP on all interfaces to see where that device is. Now, because link local addresses are, as the name implies, link local, there is a possibility of a conflict there that two devices may have the same address on different interfaces.

But there are 65,000. So that's a very rare likelihood. And as I said, it's a situation in Tiger where it doesn't work at all. In Leopard, you've got a 99.9% chance of it working. As an additional precaution, in the very rare case that you do get a conflict, the Mac actually takes precautions to try to avoid that happening.

When you connect your FireWire device or your Ethernet cable or you join the AirPort network, when the device probes to see if its address is in use, if the Mac has seen that same address in use on a different interface, then it will deny the probe. So it won't force any device to change its address, but when devices are probing, it will try to encourage them to pick non-overlapping addresses. So the net result of this is you can just plug the cables together however you want, and it will work by magic.

Future plans we have-- right now, the Bonjour APIs, register, browse, resolve, are all completely independent. You do the call, and you get back a socket that delivers the events. We've had requests from several developers who are advertising hundreds of services that they don't want hundreds of sockets. So we're working on extending the API to let you share one socket for aggregating all of the events coming back from multiple operations.

Right now in Tiger, if you use wide-area Bonjour to advertise a service on your computer, MDS Responder will talk to your local NAT gateway and set up an inbound port mapping for that service, because there's no point advertising it globally if you're behind a NAT gateway and people can't reach you.

We've had requests from developers to expose that functionality as an API in its own right, because maybe they're not wanting to use wide-area Bonjour for this particular application. If they're writing a multiplayer game that has its own game arena, then they just want to get the port mapping.

All right, we have some support for that. That's something that we're hoping to do. And the final thing that fits into this whole picture is if you have a machine at home and it's advertising with a wide area of Bonjour and it has a nap mapping so you can reach it, then if it's sleeping, you can't reach it.

So we're working on a system where when you try to connect to a home machine, your airport base station will recognize that you're accessing a machine that's sleeping and will send the wake-on-land magic packet to wake that device up for you, all transparently, automatically, with the existing Bonjour APIs. If you advertise... If you advertise a service using the register call, then those records are automatically transferred to the sleep proxy so that it knows the service you're advertising and what machine has to be woken up to provide that service.

So first obvious thing is it advertises its presence with Bonjour, as you'd expect. But the other neat thing they did, which I didn't expect--and it's always fun when people do creative things that I hadn't thought of--is they said, what about people who don't have Bonjour web browsers? So they actually have a Bonjour browser built into the base station.

So if you're using some other web browser, as long as you know the IP address of the base station, which is, of course, a burden, but as long as you know that one piece of information, you can click on Local Services, and it shows you what is discovered on the network using Bonjour. So you can buy these gateways right now from Ruckus. The version with Bonjour will probably be shipping two to three months. Something you can buy today is these little network cameras from Axis.

And when I showed my demo four years ago, the camera was big and bulky, and the image quality wasn't good, and the frame rate wasn't good, and of course, the set of experience was a nightmare because they didn't have Bonjour, and they were expensive. And how things have changed in a few years. The camera now is tiny. It's about half the size of a deck of playing cards. It does 30 frames per second at 640, 480. It's got really good image quality, really, really good low-light performance. In fact, let's try connecting to that.

You can see. So even in this low light, I mean, I can barely see you guys, but this camera, can see perfectly well. And of course, it shows up with Bonjour. I don't know what its IP address is. I don't care what its IP address is. And for a few dollars more, they have a version with wireless.

with no Ethernet cable. And I think we've got a lot of wireless networking going on here, but pretty good frame rate on the wireless version as well. So I'm really excited to see these things that I imagined four years ago, and now they're commonplace retail devices. OK, so let's switch back to the slides.

So I have shown lots of Bonjour devices that are small. This is pretty small. Apple Base Station is pretty small, including the power supply. This is the site player, Telnet. Serial port in this side advertises it as Telnet service out on the ethernet. So you can find it in terminal on OS X, go to connect to server.

USB print server from IOgear. That's pretty small. In fact, the power brick is bigger than the product. But we have a new winner, and that is-- I film, and they have made about 10 of these prototype alpha hardware, and I got mine this week. So I've got a treat for you guys today. This is the first time this has ever been seen in public, and-- This is a one-gigabyte SD card, standard kind of thing that we have in digital cameras. It's about the size of a postage stamp, about not much thicker.

But as well as being a gigabyte SD card, this has a processor, and RAM, and ROM, and 802.11g, 45 megabit wireless. So because I only just got this, I actually haven't had much time to try this. So this is going to be a bit of a Hail Mary demo. I'm going to take this card. I'm going to stick it in my camera.

And let's switch back to the demo machine. Let's try this. So what this card is doing is the processor noticed that a file was written to the file system. It powers up the wireless. It looks for a network. It looks for a machine to talk to. And it transfers the photograph that was just taken. And we should see-- So you guys probably wonder if this is a real live demo. So to prove it's real, can you put your hands in the air? We'll try that again. All right. And to the left. And to the right.

All right, so we'll see how long those take to show up. I think there's a lot of wireless traffic here today, which might be-- Oh, so one last question. If you'd like one of these wireless cards in your camera, raise your hands. I'll pass that on to the makers.

Now, I should emphasize, this is this year's blue sky vision of the future. I can't predict when this might make it into retail products. You can see from that card, it's a prototype card. Doesn't even have a label on it yet. So it probably won't be this year. But I'm really hoping that next year, this thing should be a standard product.

People have done cameras with Wi-Fi before, but they've always been clunky and hard to use. And it's what people call the dancing bear syndrome, which is that when you see a bear dancing, you're not expected to be impressed by how well it dances. You're expected to be impressed that it dances at all. And we need to get beyond the dancing bear syndrome. And I believe that this product-- plug it in the camera, snap the picture, and it's in iPhoto-- this is what we need to do to make these kind of products useful.

The mistake that people make--and a friend of mine is setting up his print server--after the five-hour struggle, he then wasn't really likely to return it to Frize because, well, it's working now, so why return it? And the mistake people make is that they assume that setup is a one-time task, but it isn't. You get a new computer, you have to set it up. You switch ISPs, you have to set it up. A visitor comes to your house and wants to print something. You have to set up their computer.

You have a power failure, and the stupid box loses its brain and forgets all its settings. You have to set it up again. And I'm sure all of us have got some piece of hardware lying around at home that used to work, and something went wrong, and we just haven't found the time to fix it again.

So the setup experience is important not just for out-of-the-box, but for continuing use and to give the products a new life. To give the products a continuing life every time you want to use it for something. To be able to do what I did here--stick it in the camera, shoot a picture, and have it work in 30 seconds. That's what it takes to make really compelling products. So let's go back to the slides, please.

All right. So our last little section here is wide-area Bonjour. We've had a lot of interest in wide-area Bonjour, and people ask, how can I experiment with this? How can I set it up and play with it myself? So wide-area Bonjour is built using the standard Berkeley Internet Name daemon.

We have an extensions daemon that Apple wrote that implements some of the non-standard features. Long-lived queries allow you to do a query to the server saying, I'm looking for printers. But rather than polling the server repeatedly to find out if there are new printers, you do a long-lived query and tell the server, here's my question. And if the answer changes, let me know.

Update leases are something that arguably should have been in the standard DNS update specification. And that is, when you do a dynamic update to put your address in the server, there's no garbage collection. If you unplug your machine and walk away, that record stays there forever. Update leases are very much like DHCP leases. There's a lifetime on the record, and if you don't refresh it, it expires. Private DNS is the third new feature that I already told you about.

Now, you can set up all these text files by hand, but I'm going to show you a different way today. And if you don't know anything about DNS and you've never done it before, and you value time at more than $15 an hour, then this might be a useful little simple tool to buy.

And this gives you a nice graphical interface for setting up your DNS server. And in the latest release this week, he added the Bonjour button. And when you click that, a sheet comes down, you fill in the settings, and you have a wide-area Bonjour server. Let's switch to the demo machine. It's cutedgesystems.com.

So what I'm going to do here is we're going to fill in the template. And we're going to make a fake domain called home. And because we want normal DNS queries to work, we're going to tell it that-- Any queries it can't answer, it should forward. And you can find that out if you type scutil --dns. It gives you a list of your machine's currently configured DNS service. If you've learned them from DHCP and you take the first address in that list and put that in as the forwarder.

We need a name server for our fake domain, and that will be me. We'll call it ns.home. So that means we need to make a host name. Click plus, ns.home, IP address. Well, that's my IP address. We can find that by typing ifconfig. And there is my IP address. So let's paste that in.

And that's all we need to set up the name server. Let's create a Bonjour service. When you click the plus button, it puts in a template. So here we have HTTP. Here's the name it will appear as. The target service being advertised doesn't have to be on this machine. You can advertise services that exist anywhere. So here we're going to use apple.com as the web page. Let's close that. Let's start the DNS server. What did I miss? Oh, retry. I think I erased that by mistake. So we start the DNS. We run Safari.

And-- And this is when we run normal Safari. We're using--this is linked local Bonjour, and this is what it found. Now, if we go into the network settings, and we tell my machine--and you can do this on any client machine, and those of you in the audience, you can try this out as well.

Join the Metro Flex NAT network, and you want to set your DNS server to be 135, which is this machine. Add home as a search domain. And now, when we look in Safari, Our wide-area page has been advertised and discovered in Safari. So I did that live on stage. With DNS Enabler, you can set up your own wide-area Bonjour server in about 60 seconds.

Now understand this is just for testing. Nobody else in the rest of the world knows about that server, which is why I had to manually put the IP address in as my DNS server. And clearly this doesn't scale. If every organization in the world did this, you have a list this long of manual IP addresses to put in. So this is a way to experiment. When you're happy with it and you see how it works, the next step is to get a sub-domain delegated to you from your parent domain or register your own domain. There are many ways to do this.

But what I just showed you here is an easy way to experiment. And what we realized is we had been unconsciously assuming that the people setting up wide area bonjour would be the DNS administrators. And they would be completely comfortable with running DNS and know how to do it and add a few records. But what we actually found is that the people who are enthusiastic about wide area bonjour are you guys. In the room now, which is not necessarily the people running the company's DNS server right now.

So you guys have to be able to go to the DNS guys and explain what you want done and why. So this test setup is an easy way for you to try it out, get comfortable with it, so that you are then equipped to go and sell the idea to the operations people running the DNS server. Let's go back to the slides, please.

So, time to wrap up. If you want more information, Craig Keithley is our evangelist. There is plenty of information on the web page. Last year, I wrote a book because one of the things that I realized--Tim O'Reilly said to me, If you try to evangelize this technology by explaining it in person one company at a time, you're going to spend the rest of your life doing it. So you need to reach a bigger audience.

So that was why I wrote this book, so that when people say, "I love Bonjour. It sounds great. Where do I start?" I can hand them a copy of the book. And when I originally wrote it, I was a bit worried that it was too thin. It's only 250 pages, and I kept trying to think of more stuff to write.

And then somebody pointed out to me that, in fact, that's the point of Bonjour. Everything you need to know about it is in 250 pages, and its simplicity is its great strength. So I actually checked at Stasis up the road here, just up on Market, turn right about four blocks. They have copies in stock, so if you want something to read on the airplane going home, you can pick up a copy there. In fact, they have an end cap display, which is really cool. I've never had an end cap display in a bookshop before.

Come to our Plugfest tonight at the Apple Campus Bash. If you've got hardware devices you want to try out, debug, have help troubleshooting, or just cool stuff you want to show us, or even if you don't have devices, if you just want to come along and have a chat and socialize with the team, we would love to see you in the piano bar at the Apple Campus.

So, summary to take away from today's session. Bonjour is really, really easy to adopt. It's a few lines of code in Ruby. If you're putting in a hardware device, especially if you run embedded Linux or a similar platform like that, you grab the Darwin code, you type make, it works, you take the rest of the afternoon off.

I've personally been on site at more than one company where we do exactly that. We check out the code, we build it, it works first time, we check it into their CVS server, and then it's done. We tell management it's showing up in Safari, it's showing up in Explorer, and that's all it takes. It makes your products easy and reliable and a pleasure to use instead of a torment. And it's free from Apple.

So, I hope with the demos I've showed you today and some of this cool hardware, I've inspired you to make cool hardware products that use Bonjour, cool software that uses Bonjour. If you're the users of network products today that you wish to use Bonjour, then tell those companies that you want them to do that. Tell them to look on the web page for documentation, contact Apple, get a copy of the book.