Okay. Hello, I'm here to talk today about the Apple Share client in Mac OS X and the AFB 3.0 protocol. I want to go over what we've done with AFP 3.0 in Mac OS X, talk about the AFP client implementation, and then go over the user authentication module SDK that allows you to write plug-in authentication for Apple Share on 10. Amen.

like to start with a bit of overview of the history and the goals of AFP 3.0, what we've got that's new, and go over what we've actually accomplished here. AFP 3.0 is similar to HFS Plus in the same way that AFP 2.2 and the earlier versions were similar to HFS, so some of the same limitations and things. So we did AFP 3.0 in order to provide support for HFS+, provide longer names, improve the Unix-like feel of the whole thing, and give you support for greater than 2 gig files, long file names, and to improve our localization, our multilingual stuff.

AFP 3.0 is, just like all the other AFP versions, is a superset of the previous ones. We did have to remove ProDOS support. We've added long Unicode names, up to 255 Unicode characters. 64-bit file sizes, that's somewhere way up in the terabytes instead of this 2-gig limit we've got today. We've added Unix permissions. We've added some optimizations to the protocol for long attentions to support directory services, much like Kerberos realms and things like that, directory service nodes from the DIRS services folks. Support for automatically reconnecting if a connection gets broken. And we now do things in GMT rather than in seconds since the-- Seconds since the Epic. Let's see. The basic new data type that we've added is an AFP name. It's in the Git file, dirparms calls and things. It's a new path type. So it's a one-byte path type, four bytes of an encoding hint, which enables the finder and Carbon to display the file name or what have you correctly. And two bytes of length, and then up to 765 bytes of UTF-8 data.

The things that we've not finished in Mac OS X, at least in the first release, is that we do not have reconnect support, we do not have long attention support, and we haven't completely hooked up with directory services to get our full directory service support. The AFP version string that we're advertising for AFP 3.0 is AFP X03. It'll be a Stump the Experts question next year, so be ready.

This is the list of the calls that we've added. The first three there, the byte range lock, read and write, are all things added to handle the larger file sizes, since we've got signed offsets and things like that in there. So we had to create some new calls for that. The getAuth methods and the loginExtended are to support directory services. It allows you to-- query a directory node for the authorization types that it supports.

The login extended allows you to specify the directory node you're logging into. It also allows you to use UTF-8 usernames, and longer usernames for that matter. Get session token and disconnect old session are used by the reconnect code. When the Apple Share client logs in initially, if you're going to be supporting reconnect and have said an appropriate bit, they'll ask for a session token, which is a way to uniquely identify that specific session from the server. And then if that connection breaks and the Apple share client wishes to attempt to reconnect, it will re-authenticate and then it will send the FP disconnect old session request and re-authenticate. handing that token that it got back from the FPGIT session token call.

And that will tell the server to release all of the locks, all of the files and things that were held by the old session that is no longer there. And that allows, hopefully, for the client to seamlessly rebuild the resources and things that were used by the old session that had gotten disconnected.

We've changed a few calls, pretty much adding new bitmaps and things like that. Server info call, we've added flag bits to say it supports reconnect and supports the DIRS services stuff. Added directory names listed in there. Get server parms, we're using UTF-8 volume names, but they still have the single byte length. So what you get is just an encoding change.

Map ID and map name map between user IDs and UTF-8 names now, as well as just standard Pascal names. And map name is the same thing the other way. Git file dirparms also has -- it's not on the list here, but it's got some bitmap changes as well to support longer file sizes.

Going on to the Apple share client in Mac OS X, the basic goal of the project was to provide the same functionalities as the Mac OS 9 client and to capitalize on what I promised last year, to have minimal changes in the APIs that you would program to it. And, you know, we've done pretty good. The experience of mounting a volume in Mac OS X is a little bit different. You've got a lot more ways to mount volumes. There's from the finder through the go-to server thing, you can use the classic chooser.

aliases work, but the login window can also be set up to mount a volume for you. You can mount things through the keychain, and the auto-mounter in Mac OS X will mount volumes silently for-- can be set up to mount volumes silently for you as you open windows and... access files and stuff. And we've added a lot of international support using the Mac OS X internationalization tools.

In terms of what you see as a developer, the Apple Share client fits into many layers in the 10 world. And we have three APIs that we're working with at the moment. As you can see, we've got some things which live and can be called from Carbon. As the finder there, there's a high-level Apple Share Client framework.

There's a core framework that gets called by command line tools, the automounter, and things like that. Then there are some things in kernel space, a plug-in file system, and a socket interface. The user authentication methods sort of straddle the carbon/noncarbon line because they have a Carbon portion which can put up HI and a noncarbon portion for those times when you're not allowed to put up HI.

Shared Volume Enumerator API, which was used by Nav Services in the network browser on Mac OS 9, has got some more calls that allow you to do more things in a more in a more Unix-y fashion, I suppose. The create shared volume enumerator from address takes the struct sock adder to do things, rather than a server name and a zone. Mount shared volume on MP. It mounts a volume on a specified mount point. And the change password call is one that we added in here.

All these things need Carbon because they can put up HI, if need be. The other API that's currently available is AFP URLs. And you've seen them if you've looked at ConnectTo sometimes. And they're very similar to FTP URLs. These URLs will allow you to add username and password to things. And in the example here, I've got a username of Leland, password of foo, at a specific server and a specific volume name.

You can also-- oh, actually going back here, I forgot. You can also specify an AppleTalk one, although that's not very useful right now. But you can do it. And that's pretty much the format. Same stuff. You can specify user authentication method names in there by inserting the auth equals UAM name construct into them. The example there-- is it legible for you folks? OK-- is the way to specify guest login in Apple Share. So that's using the no user authentication UAM.

The API is pretty simple. A way to create one, you hand it the fields and it'll spit out a URL. A way to get rid of one, a way to tell if the string that you're passing it is a UAM. A way to parse out the various bits and pieces, and a way to mount that URL on a specific mount point.

Other API which we will have as a beta SDK is--well, it's supposed to be up on the website today but it looks like it will be next week, is the User Authentication Module API. We've got a few changes from Mac OS 9 but not many. It's packaged as bundles, still has the same entry point as the old Mac OS 9, same callbacks, And I'll go over what you need to do to port a UAM from Mac OS 9 and show you an example of doing a port.

The UAMs on Mac OS X are bundles of type UAMX. They live in library file systems, Apple share authentication. They're loaded with the standard CFBundle calls. There's nothing really special about them. They're not CF plug-ins. I didn't need something that heavyweight. And it contains sub-bundles, one of which is the high-level one, one of which is the low-level one. We need the low-level bundle, the non-carbon bundle, because these things can be loaded without a user context, such as by automounter at boot time or other things like that, places where you can't go to the Windows server and put up human interface. Thank you.

The biggest API level changes are your hand to destruct SOC adder instead of an OT address. We've added a few fields to pass to the UAM the UTF-8 username and the directory names. Session reference number is now a long instead of a short. And we're not using the async callbacks 'cause you can do multi-threaded access to this stuff.

bundle, our UAM bundle is, you know, a, is a bundle and you can have inside of it a high level bundle and a low level bundle. Those things are pointed to by the info.plist. Most of the things in the info.plist are from the UAMG resource on Mac OS 9.

We've got keys for the protocol name, the maximum password length, and a dictionary which tells the Apple Share client where the high-level and low-level sub-bundles are with an identifier and a path. And it also gives you the name of the entry point. So you can change that if you want. There's also a localized string in there, which is the user visible name that will appear in the HI sometime in the future. The entry point is the same entry point as we had on Mac OS 9. It takes a UAM arg structure. It's very much a parameter block interface.

The selectors are just the same as Mac OS 9. The open when the UAM is loaded, the log in when you've requested to log in, a close, and then selectors for optionally putting up dialogs for the password for the volume selection for changing passwords, and... selectors for handling persistent data storage.

Callbacks are the same as in Mac OS 9. Callback to get additional information about the client. Callback to open the session, to send the request, to close the session. All of these things allow you to write a UAM that has no idea what network it's going to, because all of that's abstracted out in the callbacks.

In order to port a Mac OS 9 UAM, all you have to do is compile your main code and resources into the high level bundle, set up the entry points in the outer bundle, set up the Info.plist in the outer bundle, and then basically install it. Further information about this stuff can be found up on the website. There's stuff in the developer.apple.com, the Mac OS networking page there. It's got information on DIRS services and on AFP 3.0 and on the Apple Share Client APIs. Bit SDK ought to be up sometime next week. And if not, give me an email.

DuraServices docs are back up on the site as I said. And the other stuff, just take a look at the AppleshareClient.framework and AppleshareClientCore.framework stuff. Both of the other sessions that might be interesting have already occurred, so you'll have to catch them in DVD. And further stuff can be directed towards Tom Weir.