Good afternoon. My name is Rob Neville and I'm the manager of the Service Location Engineering team at Apple. And this session for those of you in the room in the dark out there is on NSL. If you came to hear about something else, you can leave. I'd like to go over some of the highlights of NSL and I'd like to start off with some of you in the room that as I was looking before the session started I recognized from past years. And some of you were fresh faces. Doesn't mean you haven't been here, it's just I didn't recognize you.

NSL came out of a team that was primarily, that Apple was primarily responsible for doing personal web sharing about four years ago. And as soon as we delivered a server on every desktop, we became acutely aware that it was difficult to find TCP IP services on the net in the same way as we were able to find personal file sharing servers or Apple share servers on the network.

And as people started moving into a more dynamic environment, where they didn't have a specific TCP IP address from one boot to the next, it became even more critical to be able to somehow put out to the world or to your intranet a way to tell people where services on your particular CPU were located. And out of that investigation and search came NSL, Network Service Location.

In an essence, in a nutshell, what NSL is, is a way for, for servers and services that are written as part of the OS or by people like you to register those services on the network and then have client-based applications find those services. Those services can be registered dynamically in much in the same way as, you know, 10 years ago you were doing an MVP register on an Apple Talk network. You can now do an NSL register and get your services registered on your network. They can be found by your client, and they can be found by your client. They can be found by your client-based applications through a common interface.

The first year that we did NSL, we basically gave you a series of APIs that allowed you And we got feedback from you. And the feedback from you was give us a common UI so that for all of our client applications we don't have to roll our own. Next year we came back and you had your Common UI and we've put that Common UI into 10, excuse me, into 9.

and into 8 before that. So it's in the classic Macintosh operating system so that your servers can register on the network. And client applications that you write that can connect to your servers or other services such as AppleScript that take advantage of NSL can access your servers over the network as long as you register.

Last year the theme was if you register, they will find you. If you don't, they won't. And as we move forward, it becomes critical for you as service providers and as developers who provide services that customers are going to try and access for you to register these in particular ways.

We've gotten more feedback from you since that time that simple URL registration, while it's good because it gives the address of the server that you're trying to talk to, may not go far enough. So as part of this particular session, we'd like to have maybe a broader Q&A or maybe even a brainstorming session towards the end to try and get your feedback on where you would like to see this technology go in the future.

NSL is shipping on the Macintosh operating system since 8.0. It's callable via the APIs. There haven't been any substantial changes in the APIs and no changes in the SDK. It's callable through AppleScript if you have an in-house kind of service or application that you're trying to write and you want to find one of the services that's available through AppleScript, you can call it through AppleScript.

And there are multiple plug-ins where you can store and/or find the services that you wish to locate on the network. You can find them via MBP. You can find them via an LDAP plug-in. You can also find them via SLP. More on SLP as we go along. On Mac OS X, we have a Carbon UI library.

The UI is callable through the APIs as well. It's also available through Apple Scripts. So if you write an Apple Script that's runnable in your 9 environment, it's also runnable in 10. We've also made some tweaks to the UI. The tweaks we've made to the UI have entailed some changes in functionality and some changes in the way that the data is organized and displayed, and we'll get to that in a little bit.

In Mac OS X, we only have 2 plug-ins. As you'll see when we get to a UI slide, you only see one, but we have 2 plug-ins in Mac OS X. We have an SLP plug-in and an MVP plug-in. The MVP plug-in is only available through low-level API calls. A lot of the services available in the Apple Talk stack are not available all the way to the session layer. We thought it probably would be confusing if we made that readily available to customers when a lot of the services that call NSL in the beginning weren't able to access those Apple Talk services.

When we were here last year we talked about having a Directory Services plug-in. We did extensive work on the Directory Services plug-in. We have a Directory Services plug-in up and running in various people's offices. It didn't make the cutoff date, didn't make the ship date for Mac OS X. We don't have an LDAP plug-in per se.

The beauty of Directory Services, especially as it relates to NSL, is if you have your data stored in primarily a static directory out there on the network, you can use Directory Services to locate the data that you wish to store out there. That gives IS departments the capability of using existing infrastructure, writing with existing tools such as PEARL to enter corporate assets or user assets in a directory of their choosing.

We thought LDAP was one that was utilized a lot, which is why we did it on 8 and 9. But they could put it in a directory of their choosing and then access that data through a common UI through NSL because we make a directory services calls. If someone comes along, such as people here in this audience, and there was a presentation yesterday on directory services, someone comes along and writes a new directory services plug-in, let's say for ActiveX, though I don't know, then you can also access the same services, find URLs inside of an ActiveX directory that you can inside of an SLP infrastructure or inside an LDAP directory. And that's where the beauty of directory services comes in. And we still intend, and as I said, we had it working in the lab, but it did not make the ship date.

We didn't--we're not doing a demonstration today because NSL is shipping with the OS. It's shipped--the UI has been shipping since Mac OS 8. In Mac OS 9, you had AppleScript capability and functionality there so you had access to the standard UI either via AppleScript or through making API calls and in 10, you It's there when you call Connect2. Connect2 is a finder call which makes a call then into our UI library. And it searches for only things in this particular release that the finder knows what to do with.

In this particular case, the only plugin that's getting executed in Mac OS X as it currently exists is the SLP plugin. That SLP plugin is put in--has been put into a sub-container currently called Local Network. When you select the Local Network, what you see then is a list of sub-scopes of that SLP network and services in the default scope.

There are some things that are different in the Mac OS X environment versus any programming that you might be doing in Mac OS 9. Threading is different. The threading mechanisms that we used in Mac OS 9 we did not have to port over to Mac OS X. You don't have to yield any thread.

We've also broken the plugins and the managers and the UI library into their own frameworks. in such a way that should, going forward, people want to make calls to the underlying managers to get that raw data as it comes in over the wire after requests. Those can be done at as low a level as we can make it. These are not just high-level APIs that can be called. These are part of the core foundation libraries. So the NSL UI library exists in the Carbon framework and the low-level manager libraries exist in the core services framework.

So if you're writing something that's going to be writing to core services, you can take advantage of making NSL API calls, getting back the data that you wish, and then you : So, I'm going to start off by displaying that in whatever format you choose. If you wish to take advantage of the common UI that we've rolled and continue to roll and to test and to fix bugs in, then you would want to make calls to the higher level UI library which is currently in Carbon.

The other thing that has changed in the NSL and the Mac OS X environment is the information is no longer available per NSL neighborhood. In addition, the protocol list is handled a little bit differently. And let me try and explain this a little bit. And if you called NSL and Mac OS 9 and you got your, quote, default Zone or your default subnet or your default scope. We had an algorithm which went and checked and see what your domain name was and that is what we put your default scope in.

And if we got information back from multiple plug-ins, we group those together in a particular grouping in the UI. So for example, if my domain was earthlink.net at home, and I had a couple of servers at my home office, they'd all show up in earthlink.net. In a small corporate environment where I may have some services that existed on a DNS server or in an LDAP directory, and I got back common data both from that and from SLP, we did the union of the data return from those and put it in what appeared to be a single scope or a single neighborhood. That's no longer done.

Basically, each individual setting as you see back to This local network will just currently return you SLP data. Our customers don't know what SLP is and probably don't care. Your customers don't care what SLP is. When AppleTalk--when and if AppleTalk is enabled in this particular environment, what you would see would be an AppleTalk container which when you clicked on would give you all the AppleTalk zones in your network and then you would have a local network container which would give you all the SLP zones in your neighborhood and you would also see those servers that would be accessible via directory services.

So each of those are in their same environment. The other thing which was mentioned briefly in the Mac OS X server The first thing that we were gathering yesterday was in Mac OS X server we're shipping an SLP server. Well, in actuality we're shipping an SLP server in Mac OS X. It's configurable through a common UI. That common UI is managed via remote administration. But that server is in essence the same server that exists and is available in every version of Mac OS X.

And it's an SLP daemon that we have. As I was mentioning, it's fully configurable through the Mac OS X server. And what does this give you? Well, this gives you the capability of subdividing your SLP network into logical, Scopes or Neighborhoods. There are scopes in SLP. But it allows you to have more than one grouping of logical devices or logical services on the network. Currently, everything goes by default into a scope known as default.

However, they don't have to. There's always a default neighborhood which is available, and that would be what people might see as their local environment. But there is also the ability to create scopes on an SLP server. And you can have more than one SLP server on a network. You don't have to have the same number of scopes on each server.

You don't have to have the same names of the same scopes on each server. If you do, and I register in a local server next door to me or down the hall, and there's a scope for, say, engineering in another building. That data will get propagated across the network so that the person who's in an engineering scope in Building 1 and myself in Building 2 will see the same data in that particular scope.

So your network will no longer appear flat. However, SLP is not a hierarchical networking architecture. It is, in essence, like Apple Talk. What it will allow you to do is segment your network. But what we've seen at Apple and as we roll this technology out internally is there are some services in Mac OS X and Mac OS 9 which register with NSL. And when you call the finder and you look for those services, primarily file services, you will see thousands of them.

That is very distressing. We attempt to solve this problem with an SLP server. Much in the same way as if there was no 255 node limit for AppleTalk, if you could have this infinitely large AppleTalk zone, you know, what would the confusion be in that particular case? So with NSL 10 Server, we're shipping an SLP scope utility.

Basically, we're hoping at some particular point, though we don't know how this is going to be, to us with SLP, this is a natural extension of your system preferences. Much in the same way as you designate what your default Apple Talk zone is, you'll get an opportunity to designate what default scope you're going to be putting your service into.

And it's also you can choose which scope you want via an Apple script in Mac OS X. Excuse me, in Mac OS 9. There's an Apple script that ships with the printer utility that allows you to choose which scope you wish to be in. And that becomes even more useful now that we're shipping an SLP server on Mac OS X.

So now we get to the point where we're going to want some of your feedback. And before I ask for your feedback here, I'd like to tell you some of the things which we're thinking about doing. And then I'd like to ask you whether or not we're going in the right direction, whether or not there are more things that you'd like to see, are there some things we haven't thought of. Basically, let us know what you think. We had some feedback last year, just one, but I wanted to bring it up again because we don't have it. We have a Carbon UI library. And we have been thinking internally about providing a Cocoa UI library.

We also are moving to use core foundation types in the SDKs and in the APIs. That would mean some changes to your code. We also are going to attempt or been thinking about making the UI much more Customizable. Currently we have a few options. You can display the text edit box or not. You can display the list of services that you want people to switch to or not, a pop-up. Fairly minor kinds of things. And we're looking at providing more options in the NSL UI library.

We also have been exploring the possibility of providing, and I would like to get your feedback on this, providing a full SLP library with support for all SLP attributes as part of the Core OS. And we're also working for and attempting to have more seamless integration with NSL as part of the Finder experience.

One of the other things that we've been looking at is a concept of meta URLs. As I mentioned at the beginning, we've been around for about four years and when we started doing this development, we were looking at solving a particular problem. Well, since NSL now has been out for three years, We're starting to get some feedback as to how people are actually using the product. One of the people that is a primary customer of our product currently is the Finder under Mac OS. And the Finder knows about files.

It knows about file systems. Well, excuse me, it doesn't know about file systems. It knows how to move files around in a file system. But it only knows what to do with files. It doesn't know what to do with web pages. From a display standpoint, it doesn't know what to do with printers. So what we're thinking about doing is having a prefix to the URL which would basically say what the type of service was.

How does this impact you? Well, if you agree and we move along with the adoption of this particular : So, in the current approach, it would mean probably registering more than one URL type. Registering the URL, I'm in a WebDAV server and registering it being an X file.

So that a service that knows--different services that know how to handle different types could say, "Give me all the types of file." Then, if you have a plug-in architecture of some sort, you don't necessarily, at run time, know which file systems are loaded or which file URLs, remote file URLs, you know how to handle.

But you say, "Give me the types file on the network. I will then pass off the URL to whatever my mounting mechanism is," which may be different for NFS, which may be different for AFP, which is different--definitely different from WebDAV. And then that's--that service will get mounted. In the current OS, this is basically the way it works, except there's no free form extensibility.

Basically the file system knows how to handle--file system right out of the box knows how to handle and mount AFP volumes, NFS volumes, and WebDAV volumes. You can at the Connect To prompt type in URLs for AFP, NFS, or HTTP and that HTTP will get you to a WebDAV if there's a WebDAV server running at that address.

And -- but it only cares about mounting file systems. It passes that URL data off to URL Mount. URL Mount then goes and mounts it in the file system. Once it's mounted in the file system, the finder deals with it as it does any other mounted volume. You may also have a need or a want to connect to a particular different types of web services or services of your own Design. So that you may design a plug-in architecture into your particular system. At runtime, you don't necessarily know what plug-ins are running.

Those systems get registered at runtime to know how to handle particular URLs. The servers that you're keeping your data on will register what services are running on their machine. The UI that you use to find those services would be dynamic, be able to find those, and then you would be able to handle them and branch those off appropriately. Rob Neville In addition, we're looking at extending the URLs to handle attribute lists. The primary impetus for this has come from printer folks. They want to be able to browse for printers that handle color printing two-sided on Wednesdays.

And There's no real way to encode that in a URL that we're used to dealing with right now. With the advent of our SLP server, network administrators and/or people who are running print shops with printers of different types, if the printers don't have this registration for themselves built into their firmware, can register these things with our SLP server and/or put it in an LDAP directory or a NetInfo directory or an ActiveX directory or whatever, because of directory services.

And then their people using the utility to access that printer can find it on the network, can switch between one or another, depending upon what the attributes are. They can put up, depending on what attributes are attributed with the registered server or the registered printer out there in the network, can change the dialog box appropriately. So what we're looking at and what we've been discussing is having a group of meta URLs.

It's Wednesday afternoon. What I understand is that at 6:00 they're going to start serving And we're at a point with NSL where we've delivered a technology. We've talked to developers, we've talked to you all out there, some of you who are developing and are using this technology in a sort of New way. New in that you've got a technology that really hasn't rolled out into production environment as of yet. But you're exploring the possibilities. Well, we don't want to make changes to NSL that