WWDC2001 Session 308

Transcript

Kind: captions Language: en good afternoon my name is Rob Neville and I'm the manager of the service location engineering team and apple and this session for those of you in the room and the dark out there is on NSL if you came to hear about something else 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 those sessions started I recognized from past years and some of you were fresh faces this doesn't mean you haven't been here just I didn't recognize you NSL came out of a team that was primarily at Apple's primarily responsible for doing personal web sharing about four years ago and as soon as we delivered a server on every desktop it 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 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 a 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 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 and much in the same way as you know ten 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 based applications through a common interface the first year that we did NSL we basically gave you a series of eight is that allowed you to register services 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 ten excuse me into nine and into eight before that so it's in a 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 Apple Script that take advantage of NSL can access your servers over the network as long as you register last year the theme was you know 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 a maybe a broader Q&A or maybe even a you know a brainstorming session towards the end to try and get your feedback and where you would like to see this technology go in the future NSL is shipping on on the Macintosh operating system since 8 oh it's Kabul via the api's there haven't been any substantial changes in the api's and no changes in the SDK it's a it's callable through apple script 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 a Perl script you can call it through apple script and there are multiple plugins where you can store and/or find the services that you wish to locate on the network you can find them via NBP you can find them via an LDAP plugin you can also find them via selphie moron SLP as we go along on Mac os10 we have a carbon UI library the UI is callable through the api's as well we also it's also available through Apple scripts so if you write an Apple script that's running in your nine environment it's also runnable intent 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 10 we only have two plugins as you'll see when we get to a UI slide you only see one but we have two plugins in Mac OS 10 we have an SLP plug-in and an MVP plugin the NBP 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 on the in the beginning weren't weren't able to access those those Apple talk services we when we were here last year we talked about having a directory services plugin we did extensive work on a directory services plugin we have a directory services plugin up and running in various people's offices it didn't make the cutoff date didn't make the ship date for for Mac OS 10 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 Perl 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 on eight nine 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 directory services calls if someone comes along such as people here in this audience and there was a presentation yesterday and 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'd 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 Apple script capability and functionality there so you had access to to the standard UI either via Apple script earth or through making API calls and in 10 it's there when you call connect to connect to is a finder call which makes a call ban into our UI library and it searches for only things that the in this particular release that the finder knows what to do with in this particular case the only plug-in that's getting executed in Mac OS 10 as it currently exists is the SLP plug-in that SLP plug-in is put in to been put into a sub container currently called local network when you select a 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 that are different in Macko in the Mac os10 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 10 we did not have to port over to Mac OS 9 we did not have to port over to Mac OS 10 you don't have to yield to 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 the raw data as it comes in over the wire after requests those can be done is at a lower level as we can make it these are not just high level api's that can be called these are part of the core foundation libraries corporate 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 displaying that in what form whatever format you choose if you wish to take advantage of the common UI that we've rolled and continue to roll in to test and to fix bugs in then you wouldn't want to make calls to the higher-level UI library which is currently in carbon the other thing that has changed in the NSL in a Mac os10 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 let me try and explain this a little bit and if you called NSL and mac os9 and you've 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 we put what we put your default scope in and if we've got information back from multiple plugins we group those together in a particular grouping in the UI so for example if my domain was Earthling dotnet at home and i had multiple 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 returned from those and put it in a single 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 neighborhood this local network this local network will just currently will just return us LP data our customers don't know what SLP is and probably don't care your customers don't care what SLP is when Apple talk when and if Apple Talk is enabled in this particular environment what you would see would be an Apple Talk container which one you clicked on would give you all the Apple talk 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 are be accessible via directory services so each of those are in their same their same environment the other thing which we talked briefly it was mentioned briefly in the Mac OS 10 server gathering yesterday was in Mac OS 10 server were we're shipping an SLP server well in actuality we're shipping an SLP server in Mac OS 10 it's configurable through a common UI that common UI has managed via remote administration but that server is in essence the same server that exists and is available in every version of Mac OS 10 and it's an SLP daemon that we have as I was mentioning it's a fully configurable through the Mac OS 10 server and what does this give you well this gives you the capability of subdividing your SLP network into logical scopes or neighborhoods their scopes and slpeeble 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 is their local environment but there is also the ability to create scopes on an SLP server and you could have more than one SLP server on a network you don't have to have the same number of scopes in each and 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 you're 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 one and myself in building two 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 will allow you to do is segment your network but what we've seen at Apple and as we rolled this technology out internally is there are some services in Mac OS 10 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 NS l 10 server were 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 access extension of your system preferences and much in the same way as you designate what your default appletalk zone is you'll get an opportunity to designate what should 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 10 excuse me in Mac OS 9 there is an apple scripts a strip chips 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 10 so now we get to the point where we're gonna 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 all right 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 so there's some things we haven't thought of basically let us know what you 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 in the SDKs and then the api's that would mean some changes to your code we also are going to attempt I've 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 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 and 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 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 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 were 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 we move along the adoption of this particular approach it would mean probably registering more than one URL type when 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 a runtime know which file systems are loaded or which file you are else remote file URLs you know how to handle but you say give me the types file on the network I will 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 web dev and then that's that service will get mounted in the current OS this is basically the way it works except there's no freeform extensibility basically the filesystem knows how to handle filesystem right out-of-the-box knows how to handle an and mount AFP volumes and efest volumes and web dev volumes you can at the connect to prompt type in URLs for AFP NFS or HTTP and that HTTP will get you to a web dev if that web dev if there's a web dev server running at that address and but it only cares about mounting file systems it passes that 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 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 your you may design a a plug-in architecture into your particular system at runtime you don't don't necessarily know what plugins are running register dos 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 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 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 net info directory or an ActiveX directory or whatever because of directory services and then there 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 and the network can change the dialog box appropriately so what we're looking at and what we've been discussing is is having a group of meta URLs so it's Wednesday afternoon what I understand is that at six o'clock they're gonna start serving pizza 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 developing and are using this technology in a sort of new way new in that you've got a technology that it really hasn't rolled out into a production environment as as of yet but are you're exploring the possibilities well we don't want to make changes to NSL that negate the work that you've been doing if there's something in NSL and in finding the services on the network which is what we're after would that work service location that you need and/or want we're listening you