My name is Stuart Chesire and I'm going to be telling you about what's new in Bonjour this year. So, for the talk today we have five sections. We are going to start with the recap, because I know a lot of you in the room are familiar with Mac OS X and Bonjour, but we have a lot of developers this year who are new to the Mac. So we'll start with a recap.

I'm going to tell you about what's new in Bonjour, in Leopard this year. We're going to cover tips and hints and reminders. If there is time at the end I want to show you some demos of some cool stuff that I have and we'll finish up with time for Q and A. So let's begin with the recap.

The point of Bonjour is the ease of USB devices but using TCPIP and TCPIP technologies like ethernet and 822 dot 11. And the reason we do that is, not just to make products that are easier to use, but also to enable a whole new sets of products that previously would not have been commercially viable.

When things are hard to use you get the support of customer support calls, you get the expensive product returns and there are many product categories that are just killed by that expense. So what Bonjour gives you is not just better ease of use for today's products, but it opens the door to possibilities for things that in the past would not of made sense and I hope to show you a couple of those later on.

So that's the goal of Bonjour and that's the most important thing to keep in mind when talking Bonjour, is why we're doing this, but of course as engineers we care about the details about how it works. And there are three simple technologists that have foundation of Bonjour and I'm not going to go into these in great detail because many of you have heard it before, but for the benefit of the new comers I'm going to give a quick recap. The three layers of technology that make up Bonjour are: Number one is link local addressing. You're not going to do much IP networking without an address.

DHCP is great. We're not competing with DHCP, but if there isn't a DHCP server on the network then simply failing is not an acceptable option. So, link local addressing is the safety net that guarantees that your hardware and software will always have a working IP address to use.

It's very simple how it works, the machine picks a random address in a designated range and sends an op request and if somebody answers that request then it picks a different address and tries again. So now we've got a bunch of machines hooked up to an ethernet hub or on a wireless network that have unique addresses, which is great, but if we don't know what those addresses are we've only solved half the problem. So that's brings us to the second technology, which is multicast DNS. Multicast DNS, very much like the first point is building on existing technologies.

This is not competing with DNS, but if you don't have a DNS server on the network or you don't have access to modify that DNS server, then multicast DNS is peer to peer distributed name resolution. Every device runs a little responder that knows its name. When you multicast a query to the whole network the device that recognizes its name sends you back a standard DNS format answer.

So that's giving its name, giving its addressing, but you still need to know what name to use. So the third layer of technology is browsing the network using DNS base service discovery, running over the aforementioned multicast DNS to discover what services are available. So, those are the technologies. That's as much as I shall say about the protocol call issues I'll say today, but you can see the website URLs where you can read the RFC's and the internet graphs and learn more.

For you software guys, at an API level there are three basic operations that cover almost everything you need to do with Bonjour. If you have a piece of software that opens a socket and binds to an address and port and listens for incoming packets of connections, then in our terminology you are running a server on the network and if you are running a server, there's normally no benefit keeping that secret. So you advertise that by registering with Bonjour, that's the first operation.

Then, when clients are looking for that particular type of service come on the network they do a Bonjour browsing operation and they multicast a query on the network and they get back a list of names of devices and services that are offering the type of service they want.

And then the third operation is resolving from that name to the address and port and the reason that resolving is a separate operation, not part of the browsing is because browsing is typically something that you do on an occasional basis and most familiar example is picking a printer.

You browse to pick a printer from the available printers on the network, but having picked it you then may print on it multiple times a day and after that you're not browsing again cause you have your default printer set and you just want to use it. But in a world of DHCP and link local with dynamic addresses, the IP address of that printer could change. What it doesn't change is its Bonjour service name.

So, at print time you resolve from name to address to get the current address of that printer and if that way if tomorrow it's rebooted, if the DHPC server is changed, if the network is renumbered, the printer that you see in your menu with a given name still connects, conceptually to the printer you want even if the IP address is different.

When we originally launched Bonjour five years ago, it feels like a long time. It's been five years since Mac OS X 10.2 was announced with Bonjour. At that time the focus was on link local networking, small scale networking, because that was the area that was really most neglected by traditional TCIP networking. It was the area most desperately in need of improvement, but now we've really solved those problems and we're taking the success of link local Bonjour back out to the wide area network.

Now, for you programmers using the APIs, unless you've made mistakes your code should still work just the same, because the APIs are the same, the difference is the underlying transport that implements it. Instead of you using peer to peer multicast we now use dynamic DNS using the existing technology that exist for DNS updates and DNS queries, we take the same semantic concepts of link local Bonjour and scale them back to the global scale.

Bonjour as I'm sure you know by now is available in Mac OS going back to 10.2, we have it for Windows. It's in Linux and BSD, we just heard this month that Open Solaris is adopting it. The slim down versions for embedded operation systems for going in printers and network cameras and things like that. So it's widely available.

When it comes to software, if Apple has software that does networking then you can be pretty sure it uses Bonjour. Same thing goes for third party software on the Mac, it does networking. When it comes to hardware products same story. The new one on this list since last year from Apple is Apple TV and those of you who have used that will, I hope tell us how easy it is to use. You plug it in and in discovers iTunes on the network. iTunes discovers your Apple TV and of course that's using Bonjour.

Ten months ago when we last met at the 2006 developer conference we had about 300 registered service types. This year it's up to 10 months later another 68. So that's one new application adopting Bonjour roughly every three working days. So adoption continues to grow and what's interesting is not just the individual application from individual companies adopting Bonjour, but just in the last month we got two registrations from other standard bodies that are adopted Bonjour for their standards.

And that's pretty rewarding to see that Bonjour is gone from being in the early days something that was seen as a Mac thing to now something that is really seen by other standard bodies as an industry standard. And that's a good point I think for us to move into, what's new.

So, in Tiger we only allocate an IPV4 link local address on the first interface in your network control panel and in Leopard we allocate link local addresses on all interfaces. And with more IP interfaces on our machines now that we do things like IP over FireWire, that helps user ability and it helps reliability.

We're big fans of IPV6. Of course we do IPV6 local addressing, ivory interface, but we recognize that a lot of devices that Macs need to communicate with may not do V6 yet. So for compatibility with those, we're doing V4 link local with, on every interface. Last year I showed you the DNS enabler from cutting edge systems that lets you turn your Mac into a wide area Bonjour server. This year I'm pleased to announce that we have officially supported UI in Leopard server.

Last year we showed you the Bonjour preference pane, you go download to play with wide area Bonjour on Tiger. This year it's an official part of the Leopard client user interface in the sharing panel. Another new thing this year which you may have seen and I'm sure some of you have is the new Airport Extreme base station and I'm going to show you that in the demo at the end. The Airport Extreme base station supports wide area Bonjour natively.

So, in the Airport set-up, you can put in a host name and credentials if you want to do secure update and now when you make manually port mappings for devices in your home that don't do wide area Bonjour the airport extreme base station will create wide area Bonjour dynamic updates automatically on their behalf. So those services are visible when you browse with wide area Bonjour.

Of course, all of you who saw the keynote on Monday would have seen the other manifestation of wide area Bonjour which is under dot Mac. Back to my Mac is dot Macs name for their wide area Bonjour service that they'll be providing for Leopard and because they know the user name and the password and other details about what host names being assigned for you. They can simplify the set-up down to a single button. You click it and it says start and it sets up everything you need to do to be doing dynamic DNS update and wide area Bonjour.

Another new feature in Leopard is something we are calling private DNS, which is where all the queries and responses are encrypted so that only authorized users can do queries for your records and the data is protected from ease droppers snooping the packets in transit. This requires Leopard because it requires the new code that knows how to do encrypted DNS.

When we shipped Bonjour originally, Mac OS X 10.2, pretty much the only language you would use was C. In 10.3 and 10.4 we added java support and on your developer seat last year at the conference we added Ruby as well and thank you. We listen to feedback and this year I am happy to tell you that we've also added Python bindings for Bonjour and we are still interested in hearing feedback for what to do after Leopard.

Perl is one we hear, maybe there are other up and coming languages that you would like to see supported and I remind everybody, this is an open source project and we mean that in absolute sincerity. So, if other people have things they want to contribute to us we're very happy to take them and in fact, that's true of both the ruby and the Python findings were contributed by external developers.

Another new thing we have in the Leopard API, we listen to find back from developers and one comment they had about the way the Bonjour APIs works is that every operation you do has a separate UNIX to main socket connection to the daemon running in the background. And we did that for simplicity. It means that applications, plug ins, libraries all in the same address page, can all do their own Bonjour operations and not interfere with each other, because everyone talks independently to the daemon.

And that was good for simplicity, but if you're creating a piece of software that registers hundreds of services, then you can use up a lot of file descriptors in your process that way. So we added a new mode that let's you share a single connection to the daemon and multiplex multiple registrations, browsers calls, resolves calls, whatever you want over a single connection.

That gives a benefit of efficiency if you're rendering lots of services. It gives a benefit of convenience, which especially is helpful for the windows developers, because you only have one socket open and when data rides on that socket you call DNS service processor results for that socket and that works out which of your call back functions needs to be called and on the Mac with CF Run Loop and CF socket that was very easy, but we found out from Windows developers that it's a little bit hard on Windows. They need to build their own house, table, their own link and search it and work out which DNS service ref the service relates to. Not difficult programming, but just a little bit of a burden, so we're glad to of fixed that.

And the other implication of this is that the more coming flag that tells you when it's time to update you're UI, you don't have to update the UI every time there's a change because that would create a lot of flickering, but when there are no more events in the queue, it's time to update the UI.

When you have four separate browsers going, the four are independent and if you're not careful you can end up updating the UI four times. We now combined the more coming flag so that if you've got multiple browsers over a single connection, the more coming flag is set as long as there is any result coming on that connection. Only when there are no more results and aggregates do you get call back with the more coming flag, not certain then you can update all your UI at once and not have it flicker.

So I'll talk through quickly how to use that. First you create a connection to the daemon and then you copy that connection and then you do your operation with the copy, but passing this flag that says share connection and that tells it to repurpose the existing connection instead of opening a new one. And then we can copy it again and then we can do another connection.

Now, you'll see here, the same callback function is being used for both browse calls, even though one is browsing for HTTP and one is browsing for FTP, but the context is different. So when your callback is called you can have a pointer to a structure or an object or some other reference that tells your callback function what is going on and helps it to recover its state efficiently and do what it needs to do.

Our other new API is NAT port mapping. This works with Apple base stations using the NAT port protocol and it works with most UP and P base stations using the internet gateway control protocol. You can take this today; you can try this out on your Leopard seed. Type DNSD dash X and if you are behind a Mac gateway it will talk to the Mac gateway and find out your public address and tell you.

The CAPI is below and those of you that have done Bonjour programming recognize that template as being very familiar. You pass the address to the service ref, which is initialized, you pass flags, you pass a bunch of parameters and the last two are always the callback function and the context, because like all the other Bonjour calls this is an asynchronous call. We don't know how long it will take to talk to the gateway, in fact you can start this operation when there is no cable connected to you machine.

The operation will hang out there waiting for something interesting to happen, you plug in the cable, your application gets a callback that says, hey, this is the IP address. If it changes, you get a new callback, telling the new IP address. So you don't have to pause, you do one call and then you get notified of be events until you cancel that operation.

This is the other form where we actually specify some more parameters and this call says, we want to the map an incoming port mapping so we can receive TCP connections on port AT and you see the result of that operation says, your private port AT has been mapped to public ports 36296 on the publbic side of the Mac gateway and it has a TTL of 3600, which means, that mapping will remain good for an hour and it's not your job to renew it, that's merely informational. The system service will keep renewing that mapping for you until you cancel the operation.

Now, just want to stress that API is exposed because certain developers wanted it for specialized things like games. I don't want you all to think that you need to do this. If you advertise a service with wide area Bonjour, we do all of this for you automatically. This is really just exposing the NAT mapping capability for specialized programs that are not using wide area Bonjour. So now we'll come on to tips and reminders.

I've talked before about the point of Bonjour is not just technology for it's own sake, it's because of what it enables and USB is very popular because of it's convenience, but it has limitations in terms of cable length and number devices and speed and what Bonjour gives you is that ease of use without sacrificing the power of flexibility of IP networking.

Now, one of the other benefits of USB apart from ease of use, is that it provides power on the cable and what's happened in recent years that I'm very happy about is the power of ethernet has come down and become affordable for consumers. So this is the Netgear power ethernet hub that I use in my house and this is another one of my favorite things which many of you've seen before, little Bonjour device.

The reason I'm showing it again now is last year you probably remember I joked that the power brick for this thing is bigger then the device itself and I said it was just crying out for power over ethernet. Well the good news is they heard that message and this year's model doesn't need a power brick It's powered off the ethernet cable.

When you make Bonjour products you can license the Bonjour logo at no cost and that's something you should do because when customers are looking for products that are reliable and easy to use, that's what they look for. And there's no charge to do that, all you have to do is run the conformist test to make sure that everything is implemented correctly and even if you don't care a lot about the logo, running the conformist test is good thing to do any way because it will help you find both bugs that you'll want to fix and help make your product better. Available today is a new release of the conformist test Version 123, we fixed a few bugs. It now runs more reliably on multi-processors, we have some bugs before about threading, those have been fixed and this is a fat binary that runs on an Intel and PowerPC.

Another thing you can license at no cost, Bonjour for Windows. Downloadable from the Apple website or you can license it to go on the CD on the box with your products. When the user runs the installer it adds a Bonjour plug in to the Internet Explorer tool bar that works just like Safari.

That was last year, this year if you want your users, you can just run Safari on Windows with the same Bonjour discovery as OS X and increasingly many of the customers will already have Safari installed, so in fact, they won't need to install anything. If you have a product like a printer or a camera or something where its user interface is through a web page, then without installing anything the user can just run Safari and Bonjour, find it, click it, connect to it and configure it.

And Safari and Bonjour on Windows provides the same wide area capabilities as on OS X and those of you who have looked here at the conference you will see there's a couple conference pages being automatically advertised, using wide area Bonjour in your Safari bookmarks. This is on Tiger and on Leopard and those same bookmarks will appear when you run Safari on Windows as well.

If you make products that use Bonjour on Windows let us know so we can add them to our Bonjour product list. We have a new release of Bonjour for Windows out today. What we've added is Vista support in the printer set-up wizard, we've added support for 64-bit clients, fixed a few bugs and brought it up to feature parity with the ten four nine version of Bonjour on the Macintosh.

We are planning to make this GM very soon, so if you have Bonjour applications, download 104 developer preview, give it a try, report bugs because there isn't much time left and the sooner we find out about the bugs the better chance that we will get them fixed before GM.

There's a question in the front row, what is GM? GM is a piece of old Apple terminology from when we used to make software on CD's and in the very early days of CD writers when the disks cost 20 dollars each, there were these golden colors blank disks and we would make a golden master and send it off to distribution. So that's the phrase that's remained at Apple.

So people keep asking why we do Bonjour for Windows and iTunes and Safari and why we working to make Windows better and journalist are starting to realize what the real reason is. And this is great quote I just saw last week, the reason we make things like Bonjour and Safari available is because we need a eco-system of reliable networking so that we can all make great products that work in that eco-system and if we have a great foundation for networking where products, software and hardware devices can work reliably, configure themselves, discover what else is on the network, advertise their services on the network, then we all have opportunities to make successful products.

If we exist in a world where nothing works reliably on the network, then the opportunities for all of us is very limited. So, every piece of user who installs Safari is installing Bonjour for Windows at the same time and that means that those same APIs that you have on Mac and Linux and Open Solaris, you also have available increasingly on Windows and you can come to rely on those and use those and write software that works just as reliably just on all those different platforms.

So now we get into more of the tips. There really is no need when you make a hardware product to put the ethernet address into the name. These are real printer names discovered on our network at Apple. I just changed the company name because I don't want to be picking on anybody in particular here. But this is very, very common that you see.

I think the mistake is that people got this assumption some how that it's necessary that the printers got to ship from the factories with the names already globally unique and that's just a mistake, because multicast DNS has automatic name conflict detention and resolution built in. You can ship two devices with the same name and when they both appear on the network they will realize they can't have the same name and one of them will automatically rename by putting a number two on the end.

So, I want to consider the three scenarios and I hope you've seen all three of them that putting 12 hexadecimal characters on the end isn't improving the user experience. One is a home user with one printer. Well clearly they only have one printer. They just need it to say, Canon 5700 or Epson whatever or HP 2800.

They just want to see the name of the printer and select it. So, in that case having a bunch of ugly computery stuff on the end isn't making a better experience for the user. The next scenario is two printers. Imagine a small dentist office, they have a printer and then they buy another one.

Well because of the way Bonjour works the second printer will see that Canon 5700 and is already taken and so it will call itself Canon 5700 2 and that is very intuitive to the users, because they had a printer and now they have a new one and the new one is number 2 and that's seem very logical and natural.

The third scenario is suppose you have a big company where they got ten printers on the network that are all the same, well I would argue even in that case, having a big list of hexadecimal numbers is not memorable at all to the human users. Having printer's numbered from 1 to 10 is better then bunch of hex-decimal numbers, but even going beyond that.

By the time you got that many printers, if you're the administrator setting them up you really do a service to your users by going in where the web browser, going to the configuration page and giving the printer a descriptive name that says where it is or what it's purpose is or some other name than just factory default. So in all three of those scenarios having the big ugly hexadecimal on the end really didn't help anybody.

Related to that, after a conflict and a name change store that name change persistently in non-volatile storage just as if the user had changed it through the web interface, because the scenario I gave of printer and printer 2 is really most compelling if the names are stable. If whichever printer is turned on first in the morning is printer and the other one is printer 2, then the identities keep flipping and that's not good. So that's why once a conflict has been detected and resolved, store the name persistently and that gives an experience that makes sense to the users.

For client software, we've seen a few applications, not too many thankfully, but we do see applications where they have a refresh button and one of the big things we've worked hard to do in Bonjour is to make so that the display is always fresh. You don't have to refresh it because you're seeing reality on the network and if you look at the Apple programs Safari, iChat, iTunes, we don't have a refresh button because the list is always fresh.

Another user interface thing, people like to use pull down menus, but the difficulty with pull down menus is that the user interface paradigm people expect is a static list of unchanging data. You pull down the font menus to look at the fonts. But the network is a dynamic changing environment and trying to meet those two goals at the same time is hard.

Windows containing lists are much more amenable to dynamic updating. People are familiar with seeing a list of files in the Finder and if you're doing an Xcode build same time. You see the files appear in the Finder as Xcode builds them and that's a much more familiar thing then pulling down a menu and having it change while you're trying to select something in it.

Leopard does support dynamic menus, but it's something you want to use very carefully because it's very easy to make a bad user interface that way. So, we really recommend use lists and windows rather then pull down menus. Go into browser mode and show the list, pick something they dismiss the window.

Another common bug we see is when browsing, you get given add events and remove events and each add event is associated with the name of the service that was discovered, the type, the domain and the interface on which it was discovered and a lot of developers have ignored the interface index.

So let me explain to you what can happen if you do that. First you do a browse call and let say the computers got ethernet and airport. So you discover that a given service is reachable by two different paths. So you get two different add events. Then the user turns airport off and the airport instance is no longer available. So you get a remove event for that.

If you then go and delete it from your user interface, you now got an incorrect user interface because the service is still reachable over ethernet, but it's disappeared from the screen and the user can't click on it. So, there are two solutions to that, when you get the add remove events, store all the data, name type domain, interface and then when you go to remove event match that up to find which instance is being removed. The four two name type domain interface index is unique. You'll get exactly one and only one remove event paired with exactly one add event.

So, that's an easy way to do it. If you are using some of the high level APIs that don't expose the interface index, you can also do that, but then you have to reference camps, because you may get two adds for the same name type domain and one remove and at that point, if you are reference counting properly you'll recognize it's still a reference count one of that service. So you shouldn't delete it from the display. Either of those solutions will work fine, but do be aware of that issue or you can have things disappear from the user interface and be very frustrating for the users.

So, when browsing, I said you get back name type and domain. Another mistake that we saw a few developers make is to ignore the domain and back in the days of link local Bonjour when the domain was always local it was always local so you could ignore it and then when you resolve you just press local. Now with wide area Bonjour you can discover non local services where the domain is Apple dot com or something else. So if you try to resolve you have to pass back the right domain.

So the easiest thing to do is store same type domain pass those same name type domains when you resolve. The interface index is actually optional when you resolve. If you don't specify the index. we will actually try all available interfaces, but you definitely need to get the name type domain right.

Another bug we've seen is ignoring the port number. When you resolve a service on Bonjour you don't just get told the IP address where the service is reachable, you get told the port number and in a world with NAT port mapping, we live in a world where pretty much every home user is behind a NAT gateway. You can't assume services will be reachable on that standard well known ports, because even if the web server is running on port 80, if you have 3 machines they can't all have the same port 80 on the outside interface. So they will have three different port numbers.

This is why Bonjour gives you the port number when it resolves. We found a few applications that where the developer didn't realize the importance of that and they ignored it and passed the well known port and then they fail to connect when they are working with wide area Bonjour and NAT port mapping. So now I'm going to try to show a few demos of this in action.

So this nice little product I got last week from La Cie. Its a FireWire hard disk, probably many of you have things like this. What's special about this is it's also got giga ethernet on it. So you can just plug it into the network. So I'm going to do that right now and we'll see what happens.

So I, when I got this I thought, I'm not going too make it to easy for the guys.

I'm going to plug it straight into the ethernet port on my computer so there's no DHCP server, let's see if they do the link local address and get that right. It came in the box with a manual and a disk, but I'm not going to bother with those. I'm just going to plug it in and see what happens. So, this thing is booting up now. I think it runs Linux. It will take a few seconds.

The light is still blinking. So I was very pleased to find that it in fact it did work without a DHCP server, it assigned itself an address and it advertised itself with Bonjour and I discovered it's in Safari and when I double click it, it finds the host name and it connects and it's got this user interface and that was how easy it was to plug it into the network and access it. So that's how you configure it in Safari.

I had a look in Leopard in the side bar and under shared computers where you saw Steve jobs show back to the Mac yesterday, this Lassie disk advertises with Bonjour and shows up and you just click it and, okay I'm not sure, okay there we go. Let's try that.

So it's running an AFP server and I copied some music onto it and I noticed in the web user interface it had this thing where it said, media. I thought, that's interesting. So I ran iTunes and it advertises iTunes compatible media server and it shows music on the network as well and it shows up in iTunes, it shows up in front row.

When we started this Bonjour work all those years ago, everybody thought it was about Macs and Windows and software applications and making the media to use and it was about that. But it wasn't just about making the stuff we did five years ago easier to use. What it was really about was making a whole new breed of products available and we had this vision of home networks where clusters of devices just configured themselves and discover what's available in their environment and advertise what services they are willing to offer to the environment and all this configures seamlessly and this box I'm showing you now is as it came out of the shrink wrap. I did not configure that or set anything up, I just plugged in the power and plugged in the ethernet and if what we did with Bonjour in some small way helped make products like that now become commercially viable and possible in today's world, then that's very rewarding.

So this is the Lassie product. It's only fair that I show you an Apple product as well. This is the new Apple Airport Extreme 822.11 base station and this doesn't have a disk in it, but this has a USB port. So I can take just any old standard external USB hard drive.

- And I told you that if we look in airport utility.

This thing is powering up. So then we discovered the base station and if you, if you look under advance in Bonjour, this is where you can enter the information for your dynamic DNS updates. Right now you can do that with your own server using the DNS enabler products or by editing the configuration products by hand or with Leopard server you can set it up.

Dot Mac is providing the back for my Mac service and we're also talking to other dynamic DNS providers. Because wide area Bonjour is built on top of dynamic DNS, it really isn't a radically new technology. It's just a new use of an existing technology. So we've been talking to TZO, which is one of the biggest dynamic DNS providers and by the time Leopard ships they're planning to be offering wide area Bonjour support.

So for those of you who don't want to run your own name server, they will run the name server for you give you wide area Bonjour capability. So you can put this information in here and when you make manual port mappings it will do the wide area Bonjour updates on behalf of those things and if you connect.

- We'll see if that shows up.

Something showed up in the sidebar. Let's see. There we go. So that USB disk that I connected to my Airport Extreme is now showing up as just another shared volume in the side bar automatically discovered with Bonjour and you can also back up to that using Time Machine.

So rather than having a FireWire disk that you carry around the house to your laptop and your iMac to backup you can just plug a USB2 disk into your Apple base station and Time Machine will automatically backup all that over the network to your machines. So, I have one last thing. I always like to end with something a bit more new and groundbreaking. Here are some things discovered with wide area Bonjour and if I turn airport on. Let's see if I can.

- I think the wireless network here may be a bit busy, but I can tell you about. I got a new thermostat at home which has a web server built into it. So,

So over the network I can see the temperature in the various rooms in the house and with the right password even change them. I didn't have a password for a while. But the risk of thermal practical jokes in the middle of the night seemed a bit too much.

Now for me in my house dropping an ethernet cable down to the thermostat wasn't a big deal. But in a lot of people's houses that's too much of a burden to adopt in this kind of product. So wouldn't it be great if we could do that kind of thing with wi-fi and classically complained about wi-fi is that it uses too much battery power and it's too expensive and I'm very happy that the price of wi-fi been coming down and the efficiency is getting much, much better.

- So what I have here is a brand new prototype of a new kids toy which is a little remote control tank, except it's not controlled by the normal kind of analog remote control. This is wi-fi.

Now this is a brand new prototype, so we'll have to see.

- It moved and then it stopped. I'm not sure.

Yeah, there maybe too much wireless interference in this room, but you can drive that around and control it, it also collision senses on the corners and they transmit back so these green circles are indicated that collision status. So, I think this is a great development, because this thing is running wi-fi, but taking about a tenth of the power of blue tooth.

So you've got wi-fi capability. You can control this with your Mac or PC, your laptop maybe even your iPhone, anything that's got wi-fi on it and that opens up the possibilities for so many home products that now instead of doing proprietary wireless communications technologies could be using standard wi-fi and all talking to each other. So with that, I think we're running out of time. Time to wrap up. Want to leave a bit of time for Q and A. If we could go back to the slides.

So to recap, Bonjour is very easy to adopt, makes your products not just easy to use, but reliable and robust and it's all open source and it's under the Apache two license You can get more information on the developer at apple dot com website at slash Bonjour or externally at zero com dot organize. If you are looking for a little light reading on the airplane back, this the O'Reilly book is a 250 pages, thin enough you can read it in a couple of hours.