Good afternoon, everybody. My name is Rob Neville, and I'm the engineering manager for Network Service Location for both Macintosh 9 and Macintosh 10. Today, we're going to be talking a little bit about both. Primarily, we're going to be talking about where we're going with Network Service Location on 10, but we'll also take questions if you have them on Mac OS 9 as well in that implementation. As I said, my name is Rob Neville. We're going to be joined by Kevin Arnold and Al Begley for Q&A and for a demo, which we'll have later.

Network Services Location, this is the third year at WWDC where we've had a session on NSL. Basically, NSL started as a way for my group, which at the time was responsible for developing personal web sharing on Mac OS 9, to allow users to actually find the web server. The initial feedback we got when we put out personal web sharing was that people couldn't find the server.

And in addition, what we found as a corporation was that people were starting to move away from traditional Apple Talk services and wanted the same type of services over TCP/IP networks. So our group came up with a solution, and that solution turned into NSL. NSL has been shipping on Mac OS 9, and it was shipping on Mac OS 8.

It's also shipping as part of Mac OS X. It's on the CD. The SDK is in the developer's kit, and you can make calls to it both from Carbon and from the lower foundation levels. It's not called from the Finder, though we will be demoing it from the Finder today.

And why we're having this particular session as opposed to, you know, just what you heard last year is that NSL, as we move forward into X, is going to be the way The Choser as such, or the legacy Mac OS 9 implementations of how you find services, changes in Mac OS X.

As services move onto, and there are more services available on TCP/IP, how you locate those services on a dynamic network, such as DHCP, NSL plays a much more critical role in how you're going to locate those services. So NSL is the way that you as service providers, as people writing services, or people writing solutions which contact servers and services on the net, can use to find those services.

In addition, if there are those of you who are from corporate infrastructures, it will assist you, perhaps, in this presentation, to think about how you want to structure your network. Because today, what we'll talk about is not only Mac OS 9 and Mac OS X and NSL in those particular environments, but what we've learned in the last two years from using and developing NSL.

Briefly, NSL is part of Mac OS 9. You don't really see the NSL user interface that often in Mac OS 9, but the primary part of Mac OS 9 where NSL is called is the network browser. NSL is not the network browser. The network browser is an application which makes low-level NSL calls to get the raw data that it then presents in a user interface. In addition, in Mac OS 9, we have a user interface library which puts up a UI which allows applications, you all, to call for your specific service.

An example of this, if you wish to use it in Mac OS 9, is in AppleScript. And you can call, choose URL from inside an AppleScript, and you'll see what AppleScript does to access NSL. And you'll see a long list of a variety of services that AppleScript knows about. And where we're going with this is we wanted NSL to be sort of like the standard file, the same analogy as standard file, for finding your services on the network.

And so an application can call our user interface, which was the feedback we got after the first year, For a particular service, remote administration, which is part of Apple Share IP 6.3, is one of the services which uses NSL to find its remote administration servers on the network. We're also part of Mac OS X. And as Mac OS X matures over the next months and years, we've structured some changes into NSL that will facilitate a lower-level functionality and a lower-level system-wide calling of NSL.

So what we've learned. Well, as I said, one of the first things that we've learned is that network browser is not NSL, and that though the user experience is very similar, There are some significant differences. For example, and we'll show in the demo, in network browser, you get all the services that Network Browser Knows About. You get file, you get browsing services, you get FTP, and you get a pretty long list.

In our user interface, the data type that you're looking for, actually the URL type that you're looking for, is how we sort that data. You can choose to show all the data all at once, or you can choose to segment it. And one of the things that we found is that when we rolled out Mac OS 9 internal to Apple, and we had NSL and people started using the network browser, without a network infrastructure, what you have is pretty much a flat list of every server on your network.

If people put all of their services in one particular what we call neighborhood, then what you have is all the servers in one area. This is sort of like what it would be if all of the addresses for the Santa Clara Valley were El Camino. That was the only street name you had, so that every particular business would have an El Camino address.

Well, that would perhaps make it very difficult to find a particular service. But if you divide up the network infrastructure, you separate out various neighborhoods, much analogous to Apple Talk zones, what you can find is that users are able to utilize your services and to navigate to find your services much more easily. Another thing we found, and we found this from customers, is that though we provide in Mac OS 9 four plug-ins, four different ways for finding URLs on the network, Apple Talk, DNS, LDAP, and SLP, your customers may not need to use all of those.

For example, your customers may have an LDAP infrastructure, and it may be easier for them, as we did at Apple, to set up a web front end for users to register a service in an LDAP directory associated with their name. So that then when I want to look up somebody's web server or their file server, that person goes onto a web page for your corporation, loads that data into an LDAP directory, and then they can find it that way. They may not need AppleTalk. They may want to turn AppleTalk off. You can't be guaranteed that any of the particular plug-ins will be available.

The other thing that we found as we made the transition from Mac OS 9 to Mac OS X is that you all didn't write any plug-ins on Mac OS 9. It's been two years. Maybe you've been doing other things. Maybe you've had it right there on the top of your list to write a plug-in for NSL. We don't think so.

For Mac OS X, we have a new technology that's coming out, and that's the Directory Services API. So as a team, what we did was we looked at how are people going to find services? How is that data going to be stored out there in the network? Well, we have our legacy AppleTalk data, so we needed an MVP plugin. People still wanted to be able to find Apple Share servers out there, personal file sharing, things like that. We had SLP. And SLP is very, very good currently for small businesses and work groups. They want to just turn off Apple Talk.

There was a hole there, and that was the fact that there aren't a lot of directory agent servers out there. As we talked about in an earlier session on the Mac OS X server software that's coming out in about the same timeframe as Mac OS X, we're going to be providing an SLP directory agent, which will facilitate your customers in setting up an SLP network.

Then there was DNS, and a lot of people aren't using DNS as a data store, but it's a more traditional mechanism by which people resolve URLs. In addition, as part of Mac OS X, with the Bind 8.2 server that we'll be providing, the ability to do registration to that server comes to fruition. So with the traditional bind for servers, you didn't have the capability of doing registrations. It was a static list.

And we were finding that not a lot of people were adopting that. With 8.2, you can have registration take place. Whether or not the users of the bind 8.2 are going to allow that is going to be up to the system's administrators. So those are the three traditionals. And on a Mac OS X, we had LDAP.

We had an LDAP library that was part of Mac OS 9. We wrote an LDAP plug-in to utilize that sort of a proof of concept. But in Mac OS X, we have the Directory Services API. So now if the data is not stored in an LDAP directory, it's stored in an Oracle database, or it's stored in a Novell network server, or it's stored in a Windows 2000 machine using Active Directory, we don't care. And we don't have to write a plug-in for each individual type of directory store that's out there.

Using Directory Services plug-in, when you write a plug-in for Directory Services, you're giving functionality to NSL right off the bat. So what we'll be providing in Mac OS X, an NBP plug-in, an SLP plug-in, We have a DNS plugin and a Directory Services API plugin. We have also taken the APIs that allow you to write plugins and made them private.

So there will not be in the SDK anything in Mac OS X which will facilitate you writing a plug-in. If you have a particular need for a plug-in to be written that can't be handled in those four categories, you need to let us know. Because as of right now, we don't see the need for writing any more plug-ins to this particular interface.

So, what you're hopefully going to take out of this is why you should use NSL in your applications, why you should use NSL on your servers and register with NSL. Because NSL is going to be the way in Mac OS X for your services and your servers to be found on the network. If you don't register, services that come along that take advantage of you, that may want to connect to your services, won't be able to find them on a TCP/IP network.

People are making the transition from Apple Talk to TCP/IP. Macintosh users are making that transition. In Mac OS 9, when they took personal file sharing, they allowed you to do that over TCP/IP. They register with NSL so that you can find this TCP/IP server without having to know the address. Now, if that address happens to be something that's changeable every time you boot your machine on a network such as DHCP, Then NSL becomes even more useful.

As we move away from static IP addresses, if I have a server or a service that doesn't have a static IP address, the URL for that address may change every time I boot that server. If I have distributed applications on desktops and I want to be able to find those distributed applications and the IP address is dynamic, I'm going to need NSL to be able to find those.

NSL, however, is just a mechanism for finding the address It's not LDAP. It's not SLP. It's not Directory Services. If you have specific data stored in those forms, if you want to write an LDAP application, You want to be able to find a remote LDAP server. Currently in Mac OS 9, in Internet Config, you put your LDAP server. If I want to go out and find other LDAP servers that are out there, and I have an LDAP-specific application, I can find those servers using NSL, but then I want to move and talk to the LDAP library to be able to do LDAP kinds of things.

The same thing with SLP. SLP, for example, at some point in the future, the trend is to put SLP into the firmware of printers. That would allow print architecture to talk SLP directly to the printers out there on the network. Well, NSL will give you the address of that particular printer, but it won't give you any more information than that.

This is a way to find the services on the network. In the same way that NBP and the AppleTalk stack is just one layer. It's just the way to locate those services on the network. NSL takes that to a level where it's AppleTalk, it's TCP/IP, you don't care. You don't care where the data is stored. You just want the address of the service that you're connecting to.

But to do that, you as servers, writers, and you as service and application providers need to use NSL to find those services on the network. The desktop in Mac OS X, and we'll be demoing this in a little bit, has a menu item that is Connect to Server. That interface may or may not change between now and the final release.

I was up here last year. We had a connect-to mechanism, and that changed over the period of time. That may change, but ostensibly, what's happening in the Macintosh, in the Mac OS X specifically, is those services that allow you to navigate through a network and define your services are going to be calling NSL. And as those things get down lower and lower and more invisible to the user, The ability to find those services is going to be through calling NSL. Once the service, the finder for example, locates a file system, it will have to know what to do.

So where we are today. We've got an SDK that's out there. There are a few applications outside of Apple that call NSL. But we've got an SDK and NSL and Mac OS 9 and going forward is fully supported. Some of the functionality in Mac OS 9, specifically the SLP plugin, and some of the new user interface, is 9-specific.

So that if you have Macintosh users who are using 8.0, they also get NSL, but they may not be able to see all of the SLP services out there. This is because the spec has transitioned and changed over time. In addition, we put in a user interface that the users can call. We added support into AppleScript. Going forward in Mac OS 9, there'll be support using Macintosh Manager. To be able to locate client machines on the network, those client machines will be registering using NSL.

So that if you're gearing a solution, Be aware that we're supporting back to Mac OS 9 only. Don't think you're going to get all the functionality all the way back to 8, even though we shipped with 8. That's an important distinction to make. We have file sharing over TCP/IP, and in a future release, what we'll be having is USB printer sharing. We'll be using NSL to find those computers that are sharing their USB printers.

Part of Mac OS X. When we made the transition to Mac OS X, we had a CarbonLib inside of Mac OS X. We made the transition over to Mac OS X. The system people came to us and they said, "This is a neat way to find services on the network. We may want to drop this down to the core of the OS." So having all of this API up here in Carbon may preclude us from being able to do some of the lowest level services and finding some of those services on the network. So what we decided to do in meeting with those teams is the user interface, the standard file analogy for getting a URL using the UI we provide is in Carbon.

The manager is in the core foundation libraries. So if you need access to the data that we use to put up in our user interface, then you need to call the manager itself. If all you need is the data that we put up in the debugged interface, and trust me, we went through a long period of debugging with the user interface so that we're stripping out duplicates and doing a lot of things inside the UI. If you call our UI, you don't have to debug that user interface. Hopefully, it'll be as bug-free as we can make it.

You may, however, still need access to the raw data. We understand that. You may want to put up something totally different as far as a user interface. That data is available to you, but you're going to have to link to the core foundation instead. And as I said, we're providing MBP, DNS, SLP, and a directory services plugin. And if you need anything more, let us know.

So as I said, NSL doesn't provide the network infrastructure. NSL probably, as it did at Apple, will show a lack of a network infrastructure, especially on TCP/IP. In a lot of companies, the TCP/IP network is relatively flat. And when you get a lot of services out there that are registering in yourcompany.com, because that's their domain name for SLP, suddenly you're going to get back to the situation that AppleTalk was in back in the mid-'80s, where you've got one -- ostensibly one big zone. And that may make it difficult. You as application and service developers can't do anything really about that. Other than perhaps evangelize to your customers that setting up a logical division of their network would be useful.

You also can tell your customers that they don't all need all the plug-ins. Particular customers that we've talked to have made a transition off of AppleTalk onto LDAP. People are waiting with bated breath to be able to implement our SLP directory agent and use SLP as a mechanism for finding their services on the network. We're going to be providing an SLP directory agent in the Mac OS X server.

The functionality for registering and creating a distributed SLP network and networking infrastructure will be available with a very nice user interface in the Mac OS X server. And as I said before, we're providing all the plugins we think you'll need. This is the only way you're going to be able to find your services on the network, other than hard coding in addresses, or having your servers do multicasting.

To all your clients. One of the other things that we found is that traditionally what happened was networking folks thought that AppleTalk was a very chatty network. And when you start putting hundreds of machines, TCP/IP machines, on the network doing multicasting, wow, suddenly TCP/IP is a very noisy protocol.

So here's an example of the NSL architecture. This isn't a typical architecture slide you'll see. What we want you to get away from this is, in Mac OS 9, you're just linking to one library. In Mac OS X, you may need to link to two. And why would you link to two? You'd link to two if you're doing a front end, point-to-point kind of solution. If you just want to get the URL, all you need to do is link to CarbonLib and use the standard get URL call. That will return you a URL.

If you wish to register a server or a service, chances are you're going to be linking into the Core Foundation already. At some point, but to register and deregister, you're going to not link to Carbon for NSL services, but you're going to link to the core foundation for the NSL manager to do a register and a deregister.

In addition, though it wasn't shown here, if you want to get access to the data that we use, When we put up our user interface, that data all comes through the NSL Manager. So if you want that data yourself, link to the NSL Manager and don't call our UI.

So, here's some of the services that are going to be using Mac OS, using NSL on Mac OS X. Mac OS X Server Administration. This is similar to the Apple Share 6.3. Server Administration. If you want to be able to find an Apple share server, or remotely administer a mail server running on top of Mac OS X, you're going to be using NSL to find that service.

Mac OS X server is going to be used to set up and configure SLP kinds of networks. List Services Apache and personal file sharing on Mac OS X will also be registering with NSL and Apple Script will as well. So we understand here that we're the last session of the day, and following this session, there's a beer bust and there are... Buses to take you over to Cupertino, where you can meet face-to-face with more of the engineers and share the camaraderie that only comes with imbibing and... The goodwill of others. So we'd like to get into the demo, and to assist me in the demo, I have Kevin Arnold, who's the SLP and NSL engineer.

Hi. So what we're going to show you today is a post-DP4 finder that's calling into NSL, and to show you what the UI looks like in NSL today, if you were to call it, that UI is probably going to change before we ship. Right now, it's an aquified version of our Platinum interface that we did on 9, but we're going to do more things to make it even more aqua-savvy. So basically, go to this connect to server that you may have seen grayed out. Bring it up. So we, basically we see a list of network, or neighborhoods, and we still have Apple Talk neighborhood that will show either a list of zones or your Apple Talk servers.

And then we also have other neighborhoods that show up. Now, you might notice that there's some kind of weird neighborhood names that show up. And this is part of what Rob was talking about with SLP and the kind of chaos that can happen in your network if it's not really structured right. And that's something that we're working on in 10 in conjunction with the server to make it more administrator-specific, a way to set this up and then it'll all look nice and clean.

So if we go into a neighborhood that we're interested in looking at, you can see that up here we have a pop-up button that shows what kind of services that the calling application is interested in seeing. And the finder wants to know about web servers or Apple share servers, so we can switch between those and see which ones are there.

Basically, once you hit connect, the UI basically returns to the application. We return that URL, and NSL is all done. And at that point, it's up to the calling application to handle that URL. And in this case, what the finder does is goes to mount. My volume, or my network, and I can go ahead and select what volume I want, and it'll show up right there on the desktop. So, that's basically it.

Thank you. So the demo you saw is real similar to what we've got in Mac OS 9. If you call AppleScript for Mac OS 9, you'll see that list is fairly long, as Kevin was alluding to. What shows up there and the names that you wish to put there, AFP servers may not make any sense to anybody, file servers might. So you pass in the string that you want to have displayed in the pop-up menu.

So we've got a feedback forum tomorrow. We're sort of piggybacking off the server services feedback forum rather than having a separate NSL feedback forum. That's tomorrow at 9:00. Mac OS X Directory Services was held this afternoon at 2:00. Hopefully those of you interested in that will have gone to that.

So, what I want you to take away from here is that the chooser is no more. If you start Mac OS X and you start, I believe, Classic real fast, you can see it briefly under the Apple menu, and you can go double-click on it, no guarantees, the way to find your services under Mac OS X going forward on both Apple Talk and TCP/IP networks is going to be with NSL. And NSL will give you the address of the service that you're looking for. You need to know what to do with that.

You need to know whether or not it's a telephone number, a street address, a file server, web server. We don't know. We'll just tell you where it is. And that we're providing the plugins that we think you will all need. And if you need more, you need to let us know. So with that, I'd like to take questions.