Okay. Well, I'm here to talk today about the AppleShare Client in Mac OS X and the AFP 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 plugin authentication for AppleShare on X.

I'd 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+ 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 2GB 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 folder, Parms 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. We've got the 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 get auth methods and the login extended 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. GetSessionToken and DisconnectOldSession are used by the Reconnect code. When the AppleShare client logs in initially, if you're going to be supporting Reconnect and have set 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 AppleShare client wishes to attempt to reconnect, it will re-authenticate and then it will send the FPDISCONNECTOLDSESSION request and is 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. 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. We've 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. Map Name is the same thing the other way. Gitfile.derp arms also has, it's not on the list here, but it's got some bitmap changes as well to support longer file sizes.

Leand Wallace: Going on to the AppleShare client in Mac OS X. The basic goal of the project was to provide the same functionalities 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. 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. From the finder through the go-to server thing, you can use the classic chooser.

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 AppleShare 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 AppleShare Client framework. There's a core framework that gets called by command line tools, the auto mouter and things like that. Then there's some things in kernel space, a plug-in file system and a socket interface. The user authentication methods sort of straddle the Carbon non-Carbon line because they have a Carbon portion which can put up HI and a non-Carbon 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 CreateSharedVolumeEnumeratorFromAdd ress takes the struct sock adder to do things rather than a server name in a zone. MountSharedVolumeOnMP 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 specify an AppleTalk one, although that's not very useful right now. Leand Wallace: So, I'm going to go ahead and start the session.

I'm going to go ahead You can specify user authentication method names in there by inserting the auth equals

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, well, it's supposed to be up on the website today, but it looks like it'll 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.

The biggest API level changes are your HANA 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 because you can do multi-threaded access to this stuff.

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 AppleShare 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 UAMR 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 login when you requested to login, the close and then selectors for optionally putting up dialogs for the password for the volume selection for changing passwords and the

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, you know, the Mac OS networking page there. It's got information on DIR services and on AFP 3.0 and on the AppleShare Client APIs. Bit SDK ought to be up sometime next week and if not, give me an email.

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.