Ladies and gentlemen, please welcome Group Manager, .Mac Base Engineering, Scott Ryder. Hi everybody, it's good to see you on this last session on Wednesday. So I was actually kind of preparing for our session yesterday and I realized that I am the only thing standing between you and dinner. So I figured what I would do is in that interest is I would just strip all the white space from my commentary.

So what we're going to do is we're going to actually have the session actually probably double or triple rate so we can actually get all the information out there to you really, really quickly and then you can get it out and go and go and go and go and go and go. Okay. No. Thank you very much.

Thank you very much. We'll be here all night. So as I said, my name is Scott Ryder. I manage the infrastructure group within .Mac. We're responsible for kind of all those backend servers that make things go. They don't let us near pixels which is probably a good thing since none of us can draw.

So, agenda, what are we going to talk about today? We're going to talk about very basically what is .Mac from a developer's perspective. What does it offer you? Why should you consider integrating your application with it? And what is it kind of fundamentally all about? We're then going to talk about...click... Hello. Here we go.

Some new features in Tiger. Specifically, if you've installed the Tiger DVDs that you got, if you look on the .Mac preferences pane, you'll notice there's a new tab on the very end called Domain. And it's not very well explained what that is. So I actually get to do a feature announcement about what it is that that tab is all about and what it does for you.

And we're going to touch very briefly on the new synchronization services in Tiger and what that does and what it means to .Mac and what it means to your app. Then, after that, we're going to talk about how you can get all the exact same integration that you've seen in Mac OS X and our iApplications over the past couple of years in your app. Basically, what we've done is we've listened to our developers. And today, we're announcing the new .Mac Kit.

The .Mac Kit is a high-level Cocoa wrapper around all the .Mac services that you would need to kind of enable a next generation of features for your application. The key is you can do all of this without network programming. There's no asynchronous. You don't have to deal with run loops. There's no threading issues.

It's a very simple API for you to use. And it just moves your application forward and gives you a whole new set of features. Again, this is at no cost to you. There's no charge for running the thousands of servers that we run. There's no charge to you for using the kit. It's just something that's available to you.

And again, and I'll hit this several times, .Mac is open standards-based. That hasn't changed. We're not inventing custom binary protocols. We're not trying to push some new standard. We're not trying to push some new standard deviation that we've come up with. These are entirely using the same web dev, the same XML, the same HTTP that we've been using for a long time. What we're simply doing is lifting the bar a bit so you don't have to do that work.

So what we hope you'll learn specifically is a brief overview of how to integrate the .Mac domain with your application, what it means to you and how to use the Rendezvous APIs that it touches on. Tiger's new synchronization services in .Mac, the new .Mac Kit, specifically what it is, when you should use it, when you should not use it, and some good call styles and of course lots and lots of code samples. Ultimately, what we want you to get is a little bit of .Mac zen.

We want you to kind of help bridge that gap for the users between their local world and the online world. That's what the kit really enables. It lets you build features that go seamlessly to the server and back again. They let two clients work together. It just makes data flow seamlessly for our customers and yours.

So, .Mac overview of developers. What does .Mac look like from a developer's perspective? First and foremost, it gave you the ability to create a new category of features. First, .Mac offers a universal namespace. This is, you know, we're at, I think, somewhere around 500,000 paying accounts or over 500,000 paying accounts that all have names in one space.

When a new user comes to us, we give them a name, there's no collisions, we don't recycle the namespace, so once a customer gets a name, it never goes away, it's theirs forever. And there's a lot of things that your app can do with this. If you think about, you know, a good example of who does this today, iChat.

Those .Mac names that you get are perfectly valid through iChat. They're free. You don't have to be a paying account. You don't have to be in any particular state. As long as you have the credential and you have the password, you're good to go with iChat. We're good with the .Mac kit. We're giving you the same ability to build iChat-like services that use those IDs, use those credentials.

With paid membership, though, there's a whole bunch of services that we provide. One of them is this always-on store and forward. The ability to kind of do, if you think of what iCal does with its publish and subscribe for calendar data. You can publish a calendar out there. One, two, a thousand people can then download and subscribe to that calendar. All the updates flow through the server.

You can do shared meta. Imagine if you want to have a workflow going and you want to put up, you know, this is the state of the project and you want to have X number of people look at that particular project state. And of course, ultimately, just like you see in iPhoto, we offer the simplest direct-to-web that's available for customers. Customers don't have to deal with server URLs. They don't have to deal with credential spacing because it's all built into the OS. With the kit, you can leverage that directly in your application and truly provide one-button publish.

Ultimately, this will help you stand out in your market. This is something that you cannot do on any other platform. That other OS doesn't offer this, even in the .Cow form. It's not something that they've done. You've not integrated the credentials like this with the system in a totally open standard way.

So .Mac from a developer's perspective. This is actually something that's been part of the service way back when it started life five years ago as iTools. We fundamentally designed this to work with desktop applications as well as online applications. If you look in your iDisk, you'll see something called the library folder. It's just like the library folder on your local hard drive, but it has a couple neat attributes. One of them is it's protected.

Users can't accidentally go into the folder and mess up data. They can't delete files. They can't overwrite files. So you can keep, you know, application state or some important files in this location and they can't be accidentally deleted by users. And we'll talk a little bit more about the library folder later.

It's designed fundamentally for a single app, multi-machine use. You can imagine your software is running in one or two or three or four of the user's Macs and you want to have a place for all those apps to coordinate with each other to keep data that they want to pass to each other.

That's what you can use the library folder in iDisk to do. It's a great place to put that meta and then read it out in multiple places and put it back and you can keep some really interesting coordination pieces there. We do that with our own applications at the .Mac layers. Another section of folders in the iDisk are the public and sites folders.

These are kind of your distribution points. They're a place that you can get public data out to users. Two ways. One is if you want to do it with the web browser, you know, with the homepage.mac.com services, anything in that sites folder can be out, can be viewed from the web. There's no credentialing. There's no extra headaches required.

Or if they want, you can put it in the iDisk. You can put things in the public folder and use iDisk.mac.com to go into that URL and you can password protect that and you can start adding some access control. The key is you can mix and match. Whatever is the appropriate model for what your application wants to achieve from both the simplicity, from a web access, from an ease of use, and from a security perspective.

You can put some data in one place, some data in the other place. It doesn't really matter. And we'll get a little bit more into this. So what ultimately could you really do by integrating .Mac with your application? Well, again, as I mentioned earlier, you can do publish and subscribe, kind of like iCal does. Imagine the ability, you know, one of my favorite editors is the Hydra client, the ability to do rendezvous-based HTML or group editing of a text document.

Imagine if you put that document on the iDisk for store and forward. Now you don't need all the clients to be online at once. Everybody can publish. Everybody can edit. The locking, we provide mechanisms for dealing with all that concurrency and it's all pretty simple. Another thing you could do is you could do, obviously, an application data store.

You Wouldn't it be nice if the user installs your application and then something horrendous happens to their machine and they have to install it again, and you didn't have to ask them all the same questions that they have already answered? If you want to keep track of where your application, get all that meta, here's a place you can put it. Put the meta on that iDisk. The next time that some calamitous thing happens and the user has to reinstall your app or wants to install it on another computer, you have a place to get all that meta back again without having to re-query them.

You can do some lightweight collaboration. Again, we offer that single namespace. So if you want to keep track of who's publishing something, you want to kind of identify a user, you want to do some meta flow or meta workflow kind of storage, maybe you pass the information computer to computer, but you keep the state of the workflow on the iDisk where anybody can get at it so they can see and you have a nice unified namespace. Usually it comes at least with an iChat ID and probably even with an email address if they're paying members. And of course, distribution.

You can do some really seamless client-to-server blending when you start bringing the .Mac domain technology in together with the .Mac technology for the offline access. So, of course, identity, as I mentioned, that single namespace gives you a lot of things. Again, think of what iChat does. It's, I want to really stress, it's not required for a fee.

To get an identity, a user comes to our website, they fill out the form, that identity is theirs for eternity. They, you know, we hope that they choose to pay for it. And, of course, the services that can go with it, but it's not required. And, of course, backup and archival, lots of great places in the iDisk to keep, you know, data that's important to users or meta that's important to your app. And ultimately, there's a lot more you can do because, as I said earlier and I will say again, .Mac is totally open standards-based.

So that means this is, while I've been talking Mac to Mac, it doesn't have to be Mac to Mac. It can be Mac to Windows. It can be Windows to Windows. It can be Windows to Linux. The key thing is by building open standards at the core, we enable you to embrace and go forward on to other platforms without having to worry about things breaking. We follow the same RFCs without modification.

So specifically, what does this offer to your app? At no cost. Remember, all of this is free to you, the developer, to integrate. We offer you access to over one-half million paying customers. These are some of Apple's best customers. They're some of your best customers. And what we find is that when they use services that are integrated, they tend to really stick with those applications. It makes your application sticky, and it makes it a delight for users to use because they really enjoy the experience they get when they go online and they go offline and their data survives.

And all the things that, oh, you can do that? And it just happens. We offer all the account management, password reset, password management, security questions, all those things, it's all managed for you. We offer very, very scalable services. For example, iDisk alone handles 7 terabytes of data down every single week. We have a half a terabyte of data come up every single week.

We have over a gigabit and a half of bandwidth that we use for the service and as we get more users we always add more capacity. All of these systems are supported and monitored 24/7. There's a bunch of very dedicated folks at .Mac that have a job that I frankly could never force myself to do, which is holding the pager of doom. The thing goes off at 9 o'clock in the night, it goes off at 1 o'clock in the morning, and if a service is down these guys will go into the office if they have to get it back up again. Very, very dedicated folks.

Being at the center means that our own servers use the WebDAV protocol to access data. So this is not something that, you know, we're telling you to do and we do something completely different. We use the same protocols, the same semantics. And then a bit about standard formats. The Internet's, you know, pushed this forward and I really want to drive it even further.

By keeping images in JPEG or keeping text in text, by keeping things in a standard format, that means it's really easy for it to flow from one service to another. If you're an application and you deal with pictures, for example, say you're doing a webcam kind of app, by uploading those pictures in JPEG, that means they're automatically accessible to iCards or automatically accessible to Homepage. You don't have to do any extra work.

So, you know, those open standard formats that we all know and love, they're just a really good thing when you start thinking about sharing things across services. There's some special behaviors that iDisk gives you. Library is, again, as I said, it can be read by all. Any application can read the contents of library, but it can only be written by a select few, and we'll talk about that.

Backup is reserved. The backup folder is for the use of our backup application. If you have--you want to do backups, you can do them in library, you can do them in other places in the iDisk. It depends on the kind of data you want to back up. And some objects, depending on where they are, and we'll go a little bit deeper, can be read without members' credentials. So be careful where you put things, and we'll talk about that. But it is key to stress, there is absolutely no situation where a user's iDisk, the contents on that disk, can be listed without credentials.

You may be able to get the object, but you may not be able to get the object if you know it exists, but you absolutely can't find out what objects exist without the owner's credentials. So the two roads to Rome. As I said, there are two ways into iDisk. One way is with WebDev. Use iDisk.mac.com, and you can go through these particular paths. Member credentials are required to do this.

Read, you can read anything in the folder structure, and those special folders I mentioned, backup, library, and software, for example, you cannot necessarily write things into. Library you can, but the other choice is you can come in via homepage.mac.com, and HomePage accesses those folders. So the key thing is objects or files that you place in movies or pictures or music or sites can be read without credential. They can't be written without it. They can't be listed without it, but they can be read without it.

And the way you would do that is you would simply say homepage.mac.com/membername, put a dot at the beginning, so like .pictures, .music, and you would be able to get in. And then you would have a list of all the files that into the contents of those particular folders.

Why WebDAV? Well, first and foremost, WebDAV is nothing more than a set of extensions on HTTP. If you want to move things around the internet, you want to do that with HTTP. It is the fastest, most scalable protocol. It is the most gateway. It is the most proxy. It is far and above the most supported. It is just the easiest way to do things. It offers very rich object management. All the uploads, downloads, there's even versioning extensions to WebDAV.

It's a very active community. If you look at kind of the open source for I/O protocols today, HTTP and WebDAV are the only two that are really still evolving actively and still changing over time. WebDAV has, for example, I think four or five specs that are even out for comments and two or three that just actually came back into being full standards. And of course, it's fully cross-platform support. Mac OS has had a WebDAV file system since 10.0.

Windows and Linux have both had WebDAV file systems for quite some time now. So it's very well supported. And this is why we've been using it for three years. This is something we know. We do 60 million WebDAV transactions per week, and that number is just going up. And it's the only thing you can scale easily. I should point out, we do 60 million WebDAV transactions with 24 servers. That's the beauty of WebDAV. It's a very scalable protocol. It's our second most popular service.

So, a little bit on open standards. They're absolutely central to our philosophy. Everything we do, we want to do it with open standards. The key is we look for standards that meet all these criteria. They're stable, they're secure, they're broadly accepted, and they really offer something different for the user. When we find a standard that meets all of those, that's when we start looking at adopting it. And obviously we use things from both of those bodies today. Many flavors of HTTP and DAV, obviously many mail things, and even XML RPC.

And for Tiger, we're adding some new stuff with DNS. We'll talk about that. So what is the .Mac domain? What is that little domain tab you see in those seeds? Well, it First and foremost, it offers us something that our users have been asking for for a long time. This is brand new in Tiger.

We're going to give every member at least one zone. So they will have a zone on the internet. It is theirs. As long as they have a paying subscription, they can publish things into it. The zone will be their member name. So for example, my name is Scott, so I'm scott.members.mac.com. And when I want to find my computers, I can publish those machines into there. So I can have work iMac or I can have home G5, all built into the same zone regardless of what IP that they have.

and this is built entirely on DNS and DNS update. This is not a custom hacked protocol that we've come up with. We've taken the existing industry standard protocols to make this work. Now that's kind of cool, but Let's bring Rendezvous into the picture. When you bring Rendezvous into the picture, what we're actually going to do is we're going to kind of make the world seem .local. We're going to kind of hide the Internet nature of things.

And so when you do a service browse on one computer, you will see all the other users' computers, whether on the local link or not. So if you want to imagine this is kind of a diagram with the Internet in the middle, what we do is we kind of make that sort of fade out. If it'll click. There we go. Fade out.

And your applications will sit on top of that. So when you're running your app, you'll come up on a PowerBook. The user could be sitting in a coffee shop. It will see the Home G5 as if they were plugged into the same network link. And all the NAT and spanning and all that in between them, all handled automatically, all handled invisibly.

Again, as I said, this is fully integrated with Rendezvous. So what do you get for free? Basically, when you log into a machine, remember there's that .Mac member account right in the preferences panel. All the other apps for that account will be seen together. The key is what we're doing is we're changing that default meaning of public or the, I'm sorry, the meaning of the default browse that you saw in the sample code for Rendezvous. So if I bring that up, Originally, it said pass the empty string and it said for the empty string, we're going to simply insert .local. In Tiger, with .Mac domain, what we're going to do is we're going to insert local and that member zone like scott.members.mac.com.

So, this is the code sample that existed when Rendezvous was first introduced. No change. Exactly the same thing. But by passing that empty string, when this comes back, you'll see that local printer sitting on the local Ethernet connection and you'll see the work G5. It'll be returned to you and it'll look like it's one link. This requires absolutely no effort. You're done. It just works.

What if you want to go beyond the base behavior? What if you want to actually do more? For example, you have an application and you want to do some of this collaboration stuff. Remember I mentioned those IDs get kind of interesting because those are the keys to find other user services. You can use their .Mac member name to compute the domain that their services would live in and then pass it into Rendezvous.

So let's take that same code sample and let's make two changes. First thing we'll do is we'll have some object that gets me a name of someone else I'm supposed to browse. So in this case, we'll say I'm supposed to browse Ryder, my last name. So comes back, members name to browse is Ryder.

So we simply compute a domain, ryder.members.mac.com, and we pass that into Rendezvous. We will now see the services that Ryder has published into his .Mac domain. So if you imagine you can go through the address book, you can find buddies, you can present any kind of person picker UI.

Once you have their .Mac ID, you have the only key you need. And with two lines of code change, you can browse and look for your application services running on that member subnet. And you don't care where those computers are. As far as all your connections and all your other hooks into the Rendezvous API, they're exactly as they always have been.

So, a little bit on security. Publishing is restricted. Obviously, you can't publish something into my domain and I can't publish something into your domain. It's restricted to the local member zone. And basically, if you call the Rendezvous API, all the right things are done for you automatically. You don't have to do anything. If the user has turned on the .Mac domain, that service will be automatically published into their zone.

Browsing, notice, doesn't require authentication. If I know your member name, I can browse your services. So this is why it has always been with Rendezvous absolutely critical that if your service is vending secure information or if it's vending personal information, it's up to you to protect it. Put some kind of password off, put some challenge response, whatever's appropriate for your app. It's your responsibility as it always has been to protect the content.

.Mac with Domain will help people find each other, but it's up to you, the developers, for whatever's the right instance for your application to protect the data. And as always, if you really want to stay in the local link, just pass .local. You don't have to do anything else.

And, you know, I encourage you very strongly, go to session number 504 at 10:30. Stuart Cheshire has all the great details on exactly how this works. Open Standards, DNS Update, and T-SIG for authentication. So even the auth that we're using to do the publish is still open standards based. So if you really wanted to, you could do a DNS update packet from a Linux machine and you could probably get it into work.

Open Standards. Very, very important. So, Sync Services. All I want to say on this is iSync is growing up. iSync is becoming an absolutely killer synchronization infrastructure for you to use in your applications. .Mac is still the core. So just like it was in iSync 1 where your data went through iDisk, in the Sync Services in Tiger it goes through your iDisk.

It lives in the library folder, but there have been a couple changes. The protocol is now pure web dev. So we're even using the same piece, you know, web dev to move that synchronization data up and down. But we do it obviously over SSL to protect the data.

The new sync services as Steve say and Bertrand say, you can define your own data classes. You have much greater flexibility in performance of how syncs are triggered because the web dev protocol is much thinner than we used to be. And this is actually built with the .Mac Kit. So we're actually using our own kit in the OS. So again, the same protocols, the same technologies, the same frameworks that are available to us that we're using to build this stuff is available to you.

Now, I want to give you one quick slide on how to use the Tiger seed that you got because, as you said, Tiger is still a cub. He's still growing up. And so there's some things, special steps you need to do in order to use .Mac domain and in order to use the Sync Services in Tiger. Just for the seed, this goes away when the product ships.

We've built a little side environment. This is an environment where we run the kind of special next generation servers that we're developing. But the key thing is this is an active development environment. We're working on this too as this Tiger moves forward. We're working on this environment at the same time.

So, you know, there's a saying that one of the engineers on the team came up with. You'll laugh, you'll cry, you'll wonder where your data went. Data durability is not guaranteed in this environment. Things will come up and will go down. So don't use accounts with data that you care about. Create a trial account and play with that.

To use this account, there's one URL you can go to. This is in your seed. It's in the release notes. It's even in the UI. And it has all the instructions on how to get things set up. And of course, this has a limited life. When Tiger comes along, this whole environment will just kind of sink back into the sand from which it came and everything will be worked fine in the production normal environment. However, I do want to mention one thing.

In that web page you will see a button that says "Reset this account." What the "Reset this account" does is if something horrendous happens and you know, somehow sync services and it gets a little wedged sideways or the DNS service gets a little wedged sideways, go push the reset button. What that does is it just blows away the store that's in that separate environment. It won't touch the main .Mac, it only resets the little side environment. So it resets that special synchronization store. That's really what it's going to reset for you.

So if you get really stuck, just hit reset and you can kind of start over again. But remember, it does delete everything and the web page makes that, I think, very, very clear. Everything we've talked about up until this point is Tiger. Now I want to talk about the .Mac Kit. And remember, the .Mac Kit runs on Jaguar, Panther, and Tiger.

I think I might have said it once: .Mac is open standards based. But there's still a relatively complex amount of network programming that has to go on in order to use this. You know, run loops, threads, CF network, CFXML, web services framework. There's a lot of pieces you have to do to weld this all together.

So why do all that if you don't have to? What we've done with the .Mac Kit is we built all that on the same infrastructure. So we're using CF network, we're using CFXML, we're doing all kind of the heavy lifting under the covers for you on our own. Even all the way down to like automatic proxy configuration. If the system is configured for proxies, the kit will automatically configure itself for proxies.

Literally, it's intended to be one call and it just works. It's a simple session-style Cocoa API. We fully support, and now I'm going to get on another horse, I mean fully support asynchronous and synchronous operation. Any transaction that you can do synchronously, you can do asynchronously. There's no difference in API.

Other key point: this is an embedded framework. This is not something that comes on the OS. This is something that you can deliver in your application package. This has a couple advantages for you. One is we move the kit forward in time. You don't have to wait for OS reps. You can deliver the kit with your application. If you know that this version of the kit is qualified for the version of the OS you want to ship, you can deliver that kit yourself regardless of how the OS changes through time.

Now, of course, it would really be bad if that kit was, "Oh, it's just five megabytes. Don't worry about it." So we've worked very, very hard. The kit is 500K, half a meg. You know, if anybody remembers floppies, that would actually fit on one. So this is a very lightweight thing because, again, we're leveraging the Mac OS infrastructure. A lot of the heavy lifting pieces are already on the system.

and as I said, Jaguar are better. 10, 2, 6 and above and we'll support them all. And it's free. It's something that you don't have to pay for. And as I've said again, we use this today. This is something that's in our app servers, it's in the new Sync Services in Tiger and as time goes forward we'll continue to use it in other things. It's the same code.

When should you use this? When is a good candidate for the kit? Well, if you're doing, you know, I'll use text edit as an example here. So your users are thinking about what they're doing in terms of file. They're opening files. They're saving files. It's a kind of a file-centric experience.

You don't need to do anything. There's no special behaviors required, right? They just want to let them save. There's a lot of work we put in over the years to make iDisk look and feel just like a hard drive to the users. Even, you know, the new local iDisk helps make that a rather performant experience for them. So don't use the kit for these.

Use the OpenSave panels and you're just done. There's no extra work. This is as it has been. But what we've had over the years, we've had many developers come to us and say, "Look, I'm not doing files here. You know, I'm doing an HTML publishing application or we're doing a workflow application or I want to write a really cool webcam.

I don't want to, you know, have users keep saving stuff and their iDisk to be mounted on the desktop and things like that. That's not what I need. You know, I'm doing relatively frequent and basically invisible background applications. That's what the kit is for. The kit is, you know, if you want to think of it, the kit is for working with objects and the existing systems are working with files.

A good example of this is, of course, iPhoto. When you click on the Homepage button or you click on the .Mac Slides button, you're not really thinking of your saving files to the iDisk. Technically, you are uploading JPEGs to the iDisk. But from the user's perspective, it's invisible. It's just kind of woven in. This is what the kit is intended to do.

So exactly what is the kit? Well, it's three classes. The first one is DM Member Account. DM Member Account is designed to kind of encapsulate everything about the .Mac members account. It pulls the information from the system, it gives you methods to validate it, it gives you methods to check if it's expiring, it gives you methods to even upgrade it or create a new one if you wish. It's basically everything you need to manage member accounts. He's kind of the key. You always start with a DM Member Account and then you start doing other things like you get a session to a particular service.

So in the 1.0 of the kit, the first session we have is iDisk sessions. And iDisk sessions manage everything that is specific about the web dev protocol, all the state, all the issues about dealing with prop finds and collections, HTML parsing and unparsing and locking and vines and redirects and blah. All done. Simple Cocoa API.

And I should point out, he handles all the international issues for you. So if you're running, the user is a Japanese user, you simply call upgrade, they'll go into the upgrade path with Japanese text. If they're an English user, they'll go into the upgrade path with English text. One call to you. You don't have to worry about managing any of the other complexities. We'll do it all. And as I said, sync or async for everything he does. And he's the key. He's how you get sessions.

Let's look at some code. As I said, DM member account represents your application to .Mac. So the first thing we ask that you do is get a unique ID. The WWDR site has had a registration service for developers to register unique IDs for their applications for many years.

Why is this important? Well, if you actually look at the .Mac servers, we talk to something like 300 to 400 unique user agent type client things every day just on the iDisk service alone. It's very hard to provide a guaranteed quality of service because we don't know necessarily are we talking to a Linux machine, are we talking to some user that's just banging us from the outside.

We want to make sure that we give your apps kind of the best experience we can and it only works if we know that it's your app that's calling into us. So by giving us this unique ID and we actually require you to do this, it will make it really easy for us to make sure that your apps kind of get, you know, somewhat a little higher quality than the ones higher priority access, if you will, for key things when there's a contention.

So you need to get this ID and pass it in the constructors, either whether you're getting an auto-released instance or you're getting kind of your own managed instance. And I just put those spaces, those dashes in there. This is where you get that four-letter creator code. The URL you need is in the docs for the kit. It's in the sample code for the kit.

There's one optional parameter. If you're going to be doing something on the iDisk that's going to be represented to the user, in other words, you expect the user to kind of go browsing through and it would be appropriate to see the name of your application, you might want to set the human readable name.

And this can be any Unicode string. You know, we recommend for right now keep it Japanese or English. But you can pass in whatever the appropriate human readable name for your app is. This is particularly important when you're dealing with some future functionality coming in the library folder. And we'll talk about that.

So get an account reference. So we'll simply pull it automatically from the system. And we'll use kind of a fictitious creator code for this. Next step. Validate those credentials. Make sure that they're good. So one call, call back here. And if it's not right, then obviously the credentials are probably invalid and you can tease it apart to figure out why they're not valid.

Once you've got the credentials, let's say we're going to use the IDIS service. Make sure the service exists. You can simply use the account and say, hey, give me a list of all the services that this user has. We'll give you back an array and you can look through the array.

We provide constants for all the things you'd expect, like sync service, or email service, or IDIS service, or web hosting service. And we provide constants for these. So you can simply check. So in this case, hey, he's got the IDIS service. We're ready to go. Or uh-oh, maybe this is an email-only account. Or maybe this is an expired account.

What is a session? He's designed to kind of be a one-to-one relationship. For this member, I want this member's iDisk service. Or for this member, I want this member's X service. It's a one-to-one relationship. So once you create a service, he's bound to the member from which you created him. For multiple iDisks, for multiple members, use multiple members. Create multiple DM member accounts and do the checks on them. offers a full feature set: upload, download, delete, make directory, move, copy, you name it, it's in there.

and he initiates transactions. Each operation, whether it's done by a member account or by an IDIS session, returns a transaction. We'll get a little bit deeper on that. The only difference is when the kit is synchronous, the transaction is automatically complete and when it's asynchronous, it may or may not be complete. So, as I said, you need a DM member account to create. So, in this case, we'll create a DM member account.

The default state is asynchronous, so we're going to flip it over to sync. Important safety tip: If you're expecting things to be synchronous, remember to set it to synchronous. Otherwise, you'll be calling into transactions as you get back and they may not have even started yet. And if you're looking for data, it will be kind of weird if you ask for it and the transaction hasn't even started. We'll just give you back nothing because we don't have anything yet.

We won't give you back an error because it hasn't errored, it just hasn't started. So make sure if you're expecting things to be synchronous, every single instance of the .Mac Kit always defaults to async. Put it to sync if you expect it to be sync. So set the state to sync. And that, start firing transactions.

Now, dealing with errors. Remember, the kits, the session doesn't do errors. The transactions do. The transactions are the guys that do all the work. So if you want to see how far a transaction is progressing, you want to see if it has an error, remember you're always going to be asking the transaction for those things, not the sessions.

One more important thing. The key thing about IDIS session, something we worked very hard to do, is you can flip the state between async and sync randomly. It's entirely up to you. So if you want to issue four transactions asynchronously and then two transactions synchronously and then four more transactions asynchronously, just simply flip the state around. The in-flight transactions will not be affected by those state changes. So if you kick the thing over into sync and you have three asyncs running, they'll just keep running.

And when your sync is done, those modifications will be queued for you and be ready to pick up when you're done with the synchronous operation. So the kit is very, very good about letting you change modes on the fly. You're not bound to one mode. You won't screw up things that are in-flight or not.

DM Transaction. He does all the work. He's the guy that moves the bits around, uploads them and downloads them, encapsulates all transaction details, all the state, all the errors, all the results. And he's created by both DM member account and by DM IDisc session. So again, if you imagine those two services sitting on the side, one is wrapped by DMI to session, one is wrapped by DM member account. They both create DM transaction and he's responsible for all the protocol specifics, whether it's XMLRPC over SSL or WebDAV via HTTP. And you can set delegates on him and he will call you back.

So, using a transaction. Some key things you can do is you can use them to obviously determine progress. You can ask the transaction, "What's the content length? How much stuff do I have to move?" And you can ask him, "How many bytes have I moved so far?" I should point out, the kit, fully thread safe. So you can do these anytime you want, from any number of threads that you want. You can just kind of bounce around. It's entirely up to you.

If you want to see how the transaction is doing in kind of an asynchronous polling model, you can simply, "Hey, what's your state?" and we provide you a whole set of constants for not started, errored, aborted, successful, all those kinds of things. And then to get the result, simple call the result function and we'll give you the result back. Pretty straightforward.

So kind of a flow. How do you use the kit synchronously? Step one, get that DM member account. Step two, validate it. Step three, create an iDisk session from it. So we'll pull the session. Step four, set it to sync. This is a synchronous example, so remember, it starts async. You've got to set it to sync. It'll stay there until you set it back. Then start pulling your transactions. Go get the work done. And when the transaction is done, you can go ahead and, if it's not an error, pull the data object out of it.

So, very simple synchronous code sample. And I'm going to go very quickly through these codes because I'm running a little short on time. And I want to show you that all the code that I'm showing you up here in the slides is included in the sample code that comes with the kit.

So, you know, don't worry about paying too much attention to it. It's all there in the kit sample code. So we're going to go ahead and get a DM member account right from the system. We're going to validate the access to make sure that this account, the credentials are good as they're stored in the system. If it's not, we're going to go ahead and deal with that. In this case, we'll set the mode to sync because this is a synchronous example. And then we'll get a session, pull the session, go start doing some work.

Once we've got that session, we'll get a path. In this case, we're just going to pull a picture from some name of image that's holding the pictures folder, created somewhere else, and we'll fire a synchronous transaction to go off and get the data down, get the data from this path. Because this is synchronous, the minute this call completes, we know the transaction is done. It's either succeeded or it has failed.

And so what we do, instead of having to deal with, "Okay, we'll check the HTTP code, now check to see if the payload is there, if there's supposed to be a payload. Well, wait a minute, this wasn't supposed to have a payload." A lot of complexity. So we provide you a very simple accessor: "Is successful." "Is successful" – depending on what the transaction is trying to do – has all the smarts to figure out, "Okay, well, the right HTTP codes for the right transactions, the right XML responses." It's all dealt with for you. Simply call "Is successful." If "Is successful" returns true, then you know the thing worked, you know that the result will be there, what you expect. So in this case, you can go ahead, "Great, it was successful.

I'm going to copy that picture out and do it in this image, in this data, and then I will go ahead and create it in this image from that data and then do whatever it is I want to do." And if not, "It wasn't successful," now you can start teasing it apart. "Was there a network error? Were the credentials bad?" Whatever.

and off you go. So some notes. Maybe I've said this once. The kit defaults to async. If you need to use it synchronously, set it to synchronously. But you can flip it back and forth anytime. There's no penalty. It just means that the very next transaction you pull will follow the new model.

A bit about the result function. We worked very hard on this, particularly for Jaguar. When you call result, if you're downloading a lot of data, we will give you back a memory mapped instance of that data. So this means if you have an application you're running on a very limited footprint machine, downloading five, you know, 100 megabyte JPEGs would be a very bad thing.

You'd kill the system performance because you're pulling all those bits in. So what we actually do is whenever you're downloading an object, we put it on a temporary file in the file system and then we return that object to you when you ask for it. So that means you can download as many things as you want asynchronously and you won't cause the machine's VM to go into swap nightmare.

And then as long as you access the objects carefully, you will be able to manage the memory very cleanly. All done within NSData. It does no—all done under the covers for you. No extra work. A little bit about asking for results before the transactions are done. If the kit's running asynchronously, if you ask the results before the transaction, if you ask the results before it's complete, we're going to give you what we've got.

This could be a good thing if it's your own format and you can deserialize it, a partial download yourself. But generally, it's probably a bad idea because you can get into some strange things. "Well, what do you mean I don't have this?" You can get to some interesting bugs where sometimes it works and sometimes it doesn't work simply based on how far the transaction's gone.

You should always check. Make sure that you've got the whole thing. Just simply check that, you know, content length and bytes downloaded so far to see if you've got everything you need. But you can do it if you want. And if you call, you know, "call result, call result, call result," we'll simply give you however many bytes we've gotten up until that point. You can do progressive downloads if you wish. Just be careful.

And again, use DM member account to pre-flight. We recommend checking three things: validate the credentials, make sure the service you need exists, and of course, it's really convenient for the users to check to see if the account is expiring. It's kind of bad if they go through all this stuff and they're really using your app and it's just great, and then they launch it the next day and they get this message saying, "Oh, by the way, all the work you did yesterday, you can't get to it because your account just expired." So if the user's account is expiring within two or three or ten days, it's probably a good thing to show them some UI saying, "Hey, we noticed your account's about to expire, and then we give you all the methods you would need to upgrade that account automatically.

You make one call if they say yes, and we'll just do the work." And again, you can do this lazily. The kit supports async. You can just fire these things off, forget about them, and they'll come back when they're done. So let's talk about async. How do you use this? It's almost exactly the same as sync. Create a DM member account, perform those validations. Create a session.

and of course the transactions where you get the data objects. So an asynchronous sample. Again, setup is exactly the same as it was except this time we're not going to call set as synchronous. So we're going to just get, imagine we got the DM member account the same as we did before. But now we're going to set the delegate. In that case it's optional but it's usually a good idea. You can set the delegate up. Let me talk a little bit about retaining right now. Well, I'll save that.

Set the delegate, create some path that holds the information I want, in this case, you know, the same name of image we did before, fire transaction, and we go off and we get the image. Then the delegate will run along and it will get messaged on the big state changes. So if everything worked, you'll get a message back, transaction was successful, there was no error. Notice we give you the transaction back.

This means you don't even need to retain those transactions. We'll do that for you. So you can imagine if something in your code style works this way, you could fire a transaction in one particular object and then the whole thing can go away. And then the delegate object will get called back and they can get the payload out of the machine.

So you don't have to do the extra work of holding the transactions and rendezvousing the response with the object that initiated it and keeping track of all that. It's all done for you automatically under the hood. You don't have to hold on to anything. We'll give you back what you need to get back.

from an error, obviously, will give you the same thing back for errors. And for canceled, will give you back the same thing if you take an asynchronous transaction and cancel it. Remember, if you set a delegate on a synchronous mode, it's not going to call back because it can't. It's synchronous. Each transaction can have a different delegate. Set the session, you set it on the session, the very next transaction that you fire will message that delegate.

With polling, you can use this to make a very responsive user interface. You can imagine, set up a timer, every second or so just pull the transaction, "Hey, how many bytes have you moved so far?" And when it's done, you'll get a nice message and it makes it real easy from a code flow just to go ahead and pull him out of the UE because he's all done and go start dealing with the object that he was trying to move. Now, hopefully that seems pretty straightforward and pretty simple, but we want to make it even simpler. So what I want to offer you here is the one-line adoption. to use the .mac kit with changing one line of code.

We offer NS File Manager replacement. So there are many really cool apps out there today that kind of integrate with .Mac and they did it on their own. They figured, "Okay, WebDef file system, I can mount the volume and I can do this and I can do that and I can move it and I can do that and I can do that." Done.

It's like, "Woof." So what we're going to let you do is if you're using the NS File Manager, take the instance where you create the file manager and replace it with that.

So with that, what I'd like to do is invite Ryan Parks up, who's a lead engineer, and Ryan and I are going to do a very quick demo for you of kind of some sample code that you get with the kit. Thanks Scott.

Can we have demo one please? So I want to share a very brief little story here. This sample app implements kind of the basic things you would expect to be able to see. You can look at account status pulled from the system. You can do web uploads, backups.

It's kind of intended to be a cookbook app, code that you can crib very simple. And I wrote it. So if it stinks, I apologize. In fact, more than once I've had my team come into my office and run out of my office shrieking, "He's using the compiler again. Run! Run for the hills!" So managers shouldn't write code. It scares engineers.

But very simply intended, the kit's designed to do the kind of basic things you would need. If you wanted to provide, say, browsing the pictures folder, you can click. You can get a list of all the pictures that exist. You can scroll down. You can find some pic. Notice if I turn off the synchronous bit, now you can see the progressors reflect their thing here. If I click very quickly, maybe I can get them. Well, there we go. You can see I had two transactions in flight at once.

So this is using the asynchronous mode. So you can see, for example, the polling for a responsive Vue. The whole app that you see here for doing web uploads, for publishing if you want to publish an HTML page, upload demo page. And then when you're all done with that, you can click view it and launch Safari, and you can see the demo page.

All the code to do all of this is maybe 30 lines spread out through a couple classes. So the kit's very, very simple to use. And what Ryan's going to do now is going to show you a little bit more complicated example. So you really want to get in the intimacies of exactly what you're doing. So you're going to get a little bit more complicated.

So you're going to get a little bit more complicated. So you're going to get a little bit more complicated. So you're going to get a little bit more complicated. So you're going to get a little bit more complicated. So you're going to get a little bit more complicated in terms of exactly what the kit is doing, you can use this. Thanks. Yeah, Scott jokes about his code writing ability, but he's actually very good.

You've seen the samples. We also have another sample app that ships with the kit. It's called iDisk Browser. And as you see, the default mode is asynchronous, just like the kit itself. And we can actually toggle between asynchronous and synchronous if we navigate through the software folder and the directories.

All of the prop finds are happening asynchronously, that the quota calculation is happening asynchronously, and we can just flip back and forth. And actually, this is a good app to look at if you're interested in learning more about using a session, the same session, and flipping between async and sync, because we're just using one iDisk session instance in this app, and we just flip between the two modes.

Basically, you double-click to download in this app and If we do an upload here, you can see the polling, the UI progress, but we get an error. And even though it had written a little bit up to this iDisk, it deleted it properly at the end. And that delete is an example of kind of a carefree async transaction. That was fired right when we learned that the transaction failed. We told the caller that it had failed but fired this delete immediately.

And we didn't have to retain that damn transaction. We didn't have to do any special handling. It just happened on its own. Basically, once you fire a DM transaction, if you're not interested in the results, you just want it to be a best efforts attempt to correct whatever problem there was. You don't have to worry about it anymore.

So this is a good app to look at if you want to learn more about basically what's available to you. If you open this side window, you can see the iDisk properties available for the various files and folders. You see things like content length, content type, whether it's a collection or not. And there's an extended attributes at path method which gives you all this data.

It's pretty useful. Also, as you click around in this app and do various things, upload things, you can see what's happening in this log and basically get an idea of what the differences are between the async and the synchronous call models. So I encourage you to take a look at the source here and appreciate it because it really flexes all the various modes you can use from polling to delegate callbacks to straight synchronous calls. Great. Thanks, Ryan. Thanks very much.

So again with the samples for the kit, we wanted to provide you either a cookbook if you just want to kind of crib the objects right out and start using the code immediately in your thing, you can do that with the .DM samples. Or if you really want to get into the intimacies of exactly how the kit works and what you can and can't do and how easy it is, we gave you the full browser app as well. And again, both the source for those is included with the kit.

So I talked about the library folder and the special behavior that it exhibits. I want to kind of double click a little bit on it, but I do want to emphasize this behavior comes with Tiger ship. This is not something you have today. Everything I've talked about with regards to the .Mac kit, you know, the Jaguar support, using it, the browser apps, all of that, the kit is 1.0. This is not a developer preview. This is the shipping instance.

We encourage you, use this in your apps, deploy this to your customers, get it out there. But these are little extra functionality you're going to get when Tiger ships. So specifically, what we're going to let your application do is create a folder inside of library application support is to hold its own data.

But you must use the name that you set with that convenience application. In other words, if your application is called My Great App with spaces, then you must set, you know, My Great App and you must create a folder called My Space Great Space App inside of there. They have to match.

And again, this is simply to help the user in organizing things when they want to see which of their software applications with the names they know them by are storing things on their iDisc and using things on their iDisc. But as I said earlier, remember the library folder and its contents are protected. This means that you are responsible for this folder. There's not a simple way for the user to go in and delete its contents.

So if, you know, you're putting things here, keep one, we'd recommend keep them small, and two, make sure that you give the user a way to delete them or to clean them up if they don't want them to live there anymore. Only your app will be allowed to read and write.

So other apps can't stomp on this folder. The user can't accidentally stomp on this folder. So, you know, again, why would you do this in the first place? This is a great place to keep that small amount of state data. You know, you have multiple installs of your app running on multiple machines for the user. And they're, you know, using the .mac domain. They all know about each other and you can do really cool peer-to-peer stuff. But you want to keep a little bit of extra state.

You can do that in the library application folder. I mean, one really cool example is you could write a webcam thing, for example, that uses the .mac domain. And if it finds the two machines directly, then it goes straight through and it does a peer-to-peer connection, high speed. But if you, you know, could always fall back and also do the direct web publishing stuff using the kit and uploading to iDisk.

So good place to keep state stuff. And of course, as I said, it's protected from accidental modification. You can't--user can't accidentally screw it up. So, how do you get it? Remember, the kit's not part of the OS. This is an embedded framework. It's a 500K framework that you need to deliver with your application as part of your application wrapper.

Real simple. Go to developer.apple.com, log in with your developer ID that they give you, and in the downloads area starting today or for some value very close to today, you should see an image there called the .Mac Kit and you should be able to download it. There is some common sense licensing that you need to agree to when you use the kit.

This is again nothing you would expect. Of course, I can encapsulate it on a slide and the lawyers have expanded it into like ten pages, but it's pretty simple stuff. Don't build bad karma. Don't build applications that do bad things. This is not part of the license. It's not what the kit is intended for. You shouldn't do it.

Member data cannot be collected or used centrally. Again, the kit does not give you any way to access the member's password. It's an important privacy thing to point out. The DM member account encapsulates it all. There's really no reason for you to need it. In a couple rare cases where you may need to capture those credentials, you can pass them in directly. But the kit won't give you access to the password. It will give you access to the member name because obviously with .mac domain, there's a lot of reasons why having that name would be useful. But don't send them to a central server. Keep them in your application.

You can keep them in your preference file. You can keep them locally on the system. Just don't send them back to some central marketing database. It's kind of a violation of just good karma from a privacy perspective. Don't create, you know, don't cause members to violate their terms of service.

You know, don't upload a gigabyte and download a gigabyte and upload a gigabyte and download a gigabyte in the background. You know, be creative. You know, do things carefully. Uploading and downloading gigabytes is just not a good thing to do for the user, even the user's perspective. Use a creator code for each app that you write.

So if you're a company and you have two or three software products and you want to use the kit in all of them, which is totally great, just make sure you use a unique code for each one of those applications. That way, you know, again, we can make sure that we give them the best experience. Download the latest release from the website.

Again, as I said, Jaguar and higher, 1026, Panther, Tiger. It's our intent that hopefully we're going to support current shipping minus one. So when Tiger comes out as the shipping OS, we hope to stay with Panther and Tiger and then whatever comes beyond Tiger. We want to try to keep both of those out there for you. But again, because this is an embedded framework, if you have a version of the kit that works for you, go ahead and deliver it.

You can deliver it with your application as long as it's functional. It's not part of the OS. And again, it includes all the sample projects and all the sample code we've been talking about up here and all the documentation for the kit as well as obviously the kit itself. And it's available today or very close to today. We still have to get the damage online, but by tomorrow, let's say, at the latest, it'll be up there.

So, kind of to wrap up, the formula is with Mac OS Tiger and .Mac domain and the new sync services and all the .Mac integration that's been available in the US for a long time, there's a lot of really cool things that the OS does. When you add that to your application using, you know, core data or core video and all the other excessive things, there's some really, really cool, cool products out there. Now, we're giving you the same tools and the same capabilities that we've had with an Apple and iApp and iSync and iMovie and iPhoto and all those places to actually have things that equal, you know, that zen.

That ability to have the user's local world, their local iLife bridge into their online life and back and forth and seamlessly. You can, you know, you want to do a direct web, one button push. We have all the tools here. You need to do it synchronously or asynchronously. You know, the kinds of apps you can create here are just, it's staggering kind of thing. We've had a lot of ideas kicking stuff around. But ultimately, you can build something you can't build on any other OS and you can do so very, very simply using one kit.

Who to contact? Obviously Xavier is a great place within WWDR. David Conway, who's our marketing guru here, is another good place if you have very specific business things you want to do with the kit or you want to do with .Mac. David's a great place to go. There's two other URLs, email addresses I want to give you.

I do want to caveat these are both kind of the black hole. Messages go in, they're read, but we don't necessarily going to respond because of the volume of email that we expect. One is .Mac Kit feedback. This is not for bugs. Obviously you have radar. You have all that infrastructure for issuing bug reports.

This is, "Hey, the API is great, but we'd really like to see the API for this particular function go this way." Or, "You know, I could really use this method on the DM transaction." So if we're getting those kind of direct API feature requests for the kit, use .Mac Kit at Mac.com. And just like consumers in the .Mac website, there's a feedback section where consumers can ask for consumer features.

So if you notice, the kit is not about, you know, taking existing web stuff and wrapping ways interfacing to it. The kit's about giving you new things that you can do when you have servers in the sky that are always on and always monitored and offer, you know, live support with unified account.

So if there's some really cool things you'd like to see from, you know, .Mac from a developer's perspective or, you know, kind of under the covers, it's not necessarily HTML in a browser, let's go ahead and kick those into .Mac Zen and we'll try to get them into the kit. So with that having been said, I'd like to invite, if I can click, yes. I'd like to invite the .Mac infrastructure team up here on stage and we can take your questions.