So I'm here to tell you about Sync Services. Here's a quick overview of the talk. I'm going to give a very quick run-through of Sync, for those of you who are new to it, and a very short overview of what we did in Tiger. Now we'll go through what our goals were for Leopard. Then the large majority of the talk will cover the new and improved features in Leopard. And we've got some demos interspersed through the talk to keep you all awake. And there's Q&A at the end.

The idea is that you come out of this talk, you'll have got an idea of some of the sync concepts so that some of the terminology that we use will be more familiar. You know what's changed between Tiger and Leopard. We've covered the changes in .max sync between Tiger and Leopard. We've got some improved tools that will help you, the developers, build sync into your applications and debug them. And I'm going to go through briefly some of our new APIs. There are actually quite a few changes, but I'm going to cover a subset thereof. .

So concepts first. I'm going to run through this very quickly. So for those of you who are sync veterans, I apologize. This is just for those of us who are new to it. So this is our sync ecosystem. We use that term because there are all of these players involved. We've got devices. We've got .Mac. We've got Apple applications and your applications. And all of these talk through the sync engine.

Now, as part of that, we keep a copy of the data that you send us. A copy of everything that you send us in something that we call the truth. That is a data repository which stores all of the per-user information. The reason we do that is that one part of sync is that certain devices, if they decide they've got confused or you've got a new phone, they will ask for a fresh copy of the data. And since we have a copy of everything, we can send them that copy. That's one aspect of it.

So what do you as an application developer have to worry about in terms of sync? Most of you aren't concerned with devices, you're writing applications. So you talk to the sync engine through the Sync Services API, and to do that, you write a sync client. A sync client can either be your application, or it can be a small tool that you write off to the side that we use when a sync is requested.

When we start a sync session, your responsibility to begin with is to push the data that you have that you want to give to the sync engine through the Sync Services API. We then take that data, compare it with the existing data, compare it with the changes that all the other clients have supplied. We did this process called mingling.

And the end result of that is we then give you back the net change. We give you back new data, some updates, perhaps some deletes, some modifies. And you store those in your proprietary data format. So the distinction here is that your application data is stored in a way specific to your application. We don't know about that. When you give data to us and take it back, it's in Sync Services record format, which is a generic data type. And the end result of that process is your application data is in sync with what's in the truth.

And what do you get for free? Well, as part of being a Sync Services client, we provide you with conflict management, which means we notice when there are conflicts, i.e. the user has made changes either on a device and in an application or on two different Macs. And we provide resolution, so we put up a UI and let the user decide which version of that data they want to keep. Oh, sorry. You get .max sync, you get device support, and we have a data change alert which alerts the user if a large number of changes have been made and they may want to intervene and accept the changes or not.

So in Tiger, we gave you all of these things. The Sync Engine, the public API was new in Tiger. We had a bunch of data classes that were all built into Mac OS X that you could use. We support third-party data classes, which several applications are already benefiting from. And you add all of these features.

So I was syncing Tiger. So what's new in Leopard? Well, when we set about deciding what we were going to put into Leopard, we had a few high level goals in mind. First of all, usability. We were looking at this from two perspectives, both user usability, i.e. the end user, your customer and our customer, make life easier for them, and secondarily, usability for you, the developer.

We also want to make the whole of sync more bulletproof. So when expected problems arise, we should do the right thing. And when unexpected problems arise, we should also try and do the right thing. Everybody likes improvements in performance, so we focused on that as well. We've tried to expand the sync ecosystem that I was describing at the beginning. So we want to have sync even more pervasive, apply it to more applications. And we want to make development easier, because if we make it easier, then more of you can adopt sync into your application. So I'll go through these topics one by one.

So for usability, what we focused on at the user level is primarily dialogues. For most people, when they see sync, especially if they've got it in automatic mode, the only thing they really see is when something unusual happens, either A large number of changes go through and they wanted to be alerted to that, or there are various We've made some simple changes to reduce the number of dialogues they see, and our big focus has been to improve the data change alert. There are two reasons for that.

As developers, if you're developing a sync application, You actually tend to have the data change alert switched on all the time because you want to see what's happening under the hood. So you as developers will see this a lot more than the average user. But secondarily, a lot of people have said, well, it's difficult to use this because we get told there are these changes, but what do we do? And what we are considering with this is when we put this alert up to say you have 10 changes in your contacts or three changes in your calendars, the rule that we have right now is very simplistic. And we're considering changing that. And I'd specifically like some feedback at the lab this afternoon on that if anybody has any opinions to share.

So what I'd like to do is I'd like to ask Paul to come up, and we're going to give you a little demo of the data change alert. We can switch the screen, right? So we have a number of users logged in at the same time on this machine, so we're going to start off with this user. Testing, you guys can all hear me? So as Andy said, I'm Paul.

I'm going to talk to you a little bit about the data change alert. And for expediency's sake, I'm going to refer to it as the DCA. So if you were a user of sync in Tiger, either as an end user or as a developer, you've probably seen these dialogues. And this is what we're talking about when we talk about the data change alert.

It's, as Andy mentioned, it's intended to alert the user that a large percentage of changes are coming into the truth and potentially give the user the ability to cancel out that sync and find out what went wrong. Now, as you can see here, we have one add and one modify, and that's not too bad.

But what do you do when you find this situation? So I remember adding a whole bunch of contacts, but I sure don't remember deleting any of them. And we got a lot of feedback that on Tiger, you guys were looking for more information. And so I'm going to show you what we did for Leopard on that.

Now, in order to make the demo go a little bit smoother, we're going to be using address book as our source of changes. And in order to allow it to pop up with a data change alert, we're going to be using this application Sync Respector. Now, we're going to talk about this a little bit later in the talk.

But for the time being, the thing to notice here is the always show data change alert. Now, as Andy mentioned, we have a number of heuristics as when we should show this alert. Among them are, is the client who's pushing in data currently a server or a device? That normally means .Mac or a phone.

Is the percentage of changes incoming greater than a threshold of the total number of records in the truth? Is there another client syncing this same data? And is there any data of this type in the truth? For example, if you are pushing in new records to a brand new data class, you don't necessarily want to alert the user for that because really this is meant as data protection. And if there's no data there, nothing to protect.

So as you can see here, we have just the default address book that you get when you create a new user. We've got the Apple computer account and we've got the me account. And by, oh, I should mention, by enabling the always show data change alert, we are now going to pop it whenever any changes come into the truth for any application.

So we're, by doing this, we're removing the restriction that only .Mac and devices show it. Now, for the sake of this demo, I'm going to be making some changes rather quickly in the hopes of completing them before At Dispute decides to trickle sync on me. I'm going to add a new card. We are going to delete the me card.

And for the Apple Computer Card, we're both going to modify a phone number. And let's add a new phone number. Yeah, well, yeah, close enough. I just feel like it's parsing that. So we're finished editing, and we're going to put I just spoke to the background, which is going to kick off a trickle sync.

And you'll notice here that we have the same alert that we've seen in Tiger. However, well, as you expect, we're both adding, modifying, and deleting a contact. But now we've got this handy dandy little more info button here. And as you can see, we're presenting to the user a lot more information.

So there are a couple points I want to make about this. As you can see here, if you've seen a conflict ever pop up in Conflict Resolver, you're going to notice that this has pretty much the same layout. And the reason for that is that we built this on top of the same underpinnings that are underneath the Conflict Resolver. And that allows us to do some pretty neat things. So as you can see here, we've got our various information that we've added. Let's have a look at a modify.

Now what I like about this is that we can not only see the new information that Irisbook is pushing in, but also the information that was there in the truth. And furthermore-- whoo! And furthermore, we're separating things out so that we can see, OK, we have a modified phone number and we have an added phone number.

And in true Apple form, we'll hold down Shift. And you can see here that we're also pulling information out of the truth as it once was to show what would have been deleted. So we've gone from what was-- let me bring that back up. Conference office airbag stays up over everything.

So we've gone from, oh, no, I've deleted a contact. I don't know what contact I've deleted to, ah, this is the contact I deleted. Now, as Andy mentioned, the goals for this are twofold. First off, we believe this is going to present to the user enough information that they can make a more informed decision as to whether or not the changes currently coming into the truth are the changes they expected to come into the truth. And secondly, this is present for you guys.

Normally, as the syncing part of your application nears its beta, you tend to run without all of the extensive sync services logging turned on and a very common development technique is simply to enable always show data change alert and then go about your day. And we're hoping that this will help you guys figure out exactly what your application is doing. And back to Andy.

All right, now onto our topic of resilience. So at the developer level, What we've done so far, in fact, we released a tool for Tiger that some of you may have already been using that allows you to do schema validation because some of the problems that we've seen in the past is people have started using schemas and they weren't actually entirely valid. We didn't trap it in time, and so we've seen shipping applications like this. So the tool should help you validate your Tiger schemas, and then in addition, we've actually got runtime validation in Leopard so that once you're running on Leopard, you won't get any further.

We've added sync anchors, which allow us to detect mismatches between your client data and the truth. So if you have two different versions, we'll now be able to detect that. The primary motivation for that was, for example, restoring from a backup. So if instead the user decides to restore one directory and they leave their Sync Services truth alone, we'll be able to detect that what we thought the client had is not the same as what the client actually has. And we've added some improved runtime error handling.

Now, the user level, our main focus again has been on .Mac sync. We're handling certain network errors better. There were some problems in early Tiger releases. We have auto retry. So for those customers who are on dodgy or low-power airport networks, we will automatically retry in a certain number of times if we have failures.

And lastly, we've added this per-data class sync. So instead of trying to sync everything at once, we split it up by data class. And the advantage of that is it means if one particular thing does not work for whatever reason, then it doesn't stop all the customer's data from syncing up to .Mac. And it gives us the benefit of having a timeout. .Mac imposes a timeout on every connection. So we get that per-data class instead of the entire transaction. Amen. And for customers who are using slow modem links, that's quite important.

So in the future, we will be adding-- this is not in the current seed, but we will be adding support for what we call schema SKU. And this is the case where, for example, you are shipping an application, but you've shipped various versions of an application. And you might have the same application on two different machines. The customer is using one at work, one at home.

But the one at work is an older version than the one at home, and the schemas do not necessarily match. So we will, at the moment that does not work. And so our advice to you currently is try and make sure that you tell your customers to keep their applications in sync or don't modify your schema in the meantime.

So, performance. Having profiled our system and the various forms of sync that we do, the fast sync, the slow sync, we've noticed that the major benefit can be gleaned from reducing the memory footprint. So we've put a certain amount of effort into reducing the number of auto-released objects that we create.

One of the things that we've done, and it's only partially done in the seed, we will be doing this fairly extensively in later drops, is modify the GUIDs. So if you have any code that may somehow be dependent on the actual format of our GUIDs, be aware of that. So we've removed the prefix, and that has a surprisingly large effect on the application footprint.

In addition, we've changed the way we handle large NSDatas. So we've got feedback both from you and from customers that because, as I mentioned earlier, in the truth, we keep a copy of all your data. We also keep copies in the client side, and then you keep copies. So having multiple copies of large images, for example, or PDF files of the equivalent DNS data representation thereof is rather space consuming.

So what we've added is a mechanism that essentially takes one copy of this NSData the first time you sync, uniques it, and then from then on, what we deal with is these proxy objects. So the first sync doesn't change, but from then on, in memory, we just use this proxy representation, and that keeps the footprint down. So if you go and change your NSData, obviously, we'll have to get the new version. But in the case of a fast sync where most of your objects and most of the attributes of an object are not changing, it's a really big win.

And we fixed a number of bugs where we triggered a refresh sync for no good reason. So I just wanted to cover the effect of these data wrappers, as we call them. This is a rather, unfortunately somebody took the, you can't see the bottom line, but this covers a range from zero to 512 kilobytes, so we don't expect people to be syncing too many half a megabyte documents around. But as you can see in Tiger, essentially our memory usage was linear, and in Leopard, Really flat. And we do pay a small price right at the beginning, and that knee is around about 8 kilobytes.

But overall our footprint for syncing large numbers of large objects is really, really down. And the benefit of this is that the time it takes to sync is significantly reduced, and that's something that the customers will see straight away. And again, this is a blown up of the first 16 kilobytes of data.

So the other thing we've had feedback about is from our .Mac customers, and again, you, the developers, that they've been seeing timeouts, as I mentioned earlier, for example, with .Mac. And what I wanted to remind you is that there are certain things that you can do with your sync client and with your schema to improve the life of our end user customers. The thing to remember is that not everybody has a high-speed DSL or T1 line, so they've got very limited bandwidth.

And what we want to try and do is to send as little bit, as small amount of data back and forth as possible. So the key to that is to structure your schema so that the elements of it are segmented nicely and that you don't have one large blob. Because if you give us one large blob, we can't really delta it and so we have to send a large blob each time. And that's just going to take a long time. There's nothing we can do about it.

And what we want to try and do is to send as little bit, as small amount of data back and forth as possible. So the key to that is to structure your schema so that the elements of it are segmented nicely and that you don't have one large blob.

So we want to expand sync. Our customers love it. So what we've got in Leopard is that a whole bunch of new features, which we think people will really get excited about. We've added new data classes for the Doc dashboard. Mail Notes is not ready yet, but that will be coming. And Preferences is a big one. I'll cover that more in detail.

And we're also going to support schema extensions for all data classes. And this is-- This is something that was available in Tiger, but it was restricted slightly because the main data classes did not support it. And there are some ramifications there, which I will again go into a little bit more detail.

And we've added some integration with File Sync. File Sync is a technology used for portable home directories, which is a 10-server feature, and iDisk. And what we've added is the capability for you, a sync client, to specify that you're going to deal with syncing these These files or the contents of these files using Sync Services and so there is no need for File Sync to do it for you. And it's implemented very simply as an iSync client. And there'll be more information available forthcoming.

So I'm going to talk in quite a bit of detail about preferences sync. This is new in Leopard.

So be careful what you wish for because we are doing every application. So the outcome of this is that if your application is a document-based application, you don't want to sync the documents for whatever reason, but you have a bunch of settings, maybe we're going to do all of your sync for free. We will just take all of those preferences, and if people check the checkbox, we'll sync them to all their machines. And we sync all preferences by default. But it's not quite all.

Obviously, we only know about preferences which live within the preferences scheme. So that's anything based on CFPreferences and anything based on NS user defaults. And we don't sync system defaults. That doesn't make any sense. So these are user application defaults. Now we've excluded some deliberately. There are some specific application domains which we don't sync because they don't make any sense, or because they're already synced by Sync Services. By host preferences are not synced.

By host preferences, in case you're unfamiliar with it, are meant to be preferences that are somehow machine specific. And obviously translating them from one machine to another would not make sense. So one example of this may be if you, for whatever reason, you stored a license information in preferences and you do per machine licensing, then you would expect that would be a by host preference. Another example would be something related to display size or something hardware specific.

We also filter out certain things like NS Window Frames. If you have a different display, your window's going to appear in a different position. Wouldn't make much sense to try and keep syncing those around. We also filter those out because that would be a performance drain on the system. There would be too many changes to deal with.

But most importantly, as far as application developers are concerned, the application can choose to opt out if they want. There are two mechanisms available by which you can opt out. The first way is to modify the application Info.plist. Simply add a key. with a value, and the value is just an array with a list of keys which you don't want us to sync.

And the advantage of that over the secondary scheme is that we look at each application before we go sync them, and that means your application doesn't have to run at all before we go and examine it. The secondary mechanism by which we just look in the preferences for that application itself, obviously you have to at least run the application once so it generated a preference file. We look at the exclusion list in that order, so the preferences settings will override defaults in the Info.plist such that if you choose, you can make this opt-in, opt-out mechanism a default in your own application, if that makes sense.

Now the idea behind this whole thing is that a lot of us, if we're in an education environment or an enterprise environment, are used to using network home directories. Now the idea behind this whole thing is that a lot of us, if we're in an education environment or an enterprise environment, are used to using network home directories.

So what we're doing with Preferences Sync is essentially emulating a network home directory experience, but using the sync mechanism. So we think that's going to bring a lot of the advantages to network homes to people who just haven't got the... The will or the interest in setting up a server and network homes and all of that complexity.

The will or the interest in setting up a server and network homes and all of that complexity. Now, there probably aren't that many typical users in the audience, so what we're going to do is look at what a developer might have set up. So in this case, we're trying to do a demo, so we've We've set up terminal with large fonts and some funky translucency. And we've got Xcode set up to use a ridiculous font so that you guys can actually see it. So now we'll switch to another user, which is our actual demo user.

And as you can see, he's set up to sync the dock and preferences. And just take a look at the dock. The dock at the moment is just a default. This is a first time sync, just to prove that we're not doing anything on the hand. and we're going to choose to take what was synced onto .Mac and replace what's on the computer. So you can see the dock's resized.

And at this point, what I will mention is that in reference to performance, when I was talking about large NSDatas, probably what you want to do is not store large NSDatas in your preferences. It was always a good idea anyway, but now this is sort of reinforcing the fact. And we open a new terminal window. We've got the new preferences. You can see the old terminal window that was there before is small font. Now we've got the big font. And save with Xcode, so we got the new font. OK. Thank you, Karl.

Now, I'm going to talk about schema extensions. Now, again, for those of us who are relatively new to sync, Schema extensions are the ability to take an existing schema which describes some data class, like contacts, bookmarks, mail accounts, and extend them for your own purposes. So you can add attributes, you can add entities, or relationships. And this was fully available in Tiger, and several applications have taken advantage of it.

But there were a few limitations. We would... If you... added some schema extensions to one of our shipping classes. We would sync them via .mac, except for the three major ones: bookmarks, calendars, and contacts. And this limitation was due to Panther compatibility. So to maintain the ability to just have the Panther machines talk to Tiger machines through .Mac, we had to restrict that. So in Leopard, we are actually enabling all the schema extensions through .Mac for all of those data classes.

So the big deal here is there is a transition involved. And some of you may have noticed it in the release notes or in the notes that were on the Leopard DVD. So in order for this to work on Tiger, for this developer seed, You have to actually run a transition script to switch your Tiger machine from the old way of doing things to the new way to sync to .Mac. Just for these three data classes.

And that's if you want to sync your Leopard machine with your Tiger machine. If you just upgrade your Tiger machine to Leopard, you're good to go. But if you want to leave a Tiger machine and you have a Leopard machine and you want to sync your contacts, your calendars, your bookmarks between those two, for now, you need to run the script that we provide.

And the other limitation here is that Leopard is no longer going to sync to Panther. They're essentially talking to two different places in the sky. And a transition tiger machine is effectively going to be doing the same thing as Leopard, and so they won't be able to sync with Panther. So this is a little visual of what we have. In Panther, we didn't support schema extensions at all. In Tiger, we supported it for a subset thereof. And in Leopard, we fully support it. And then when you run your transition script, they're supported in Tiger as well.

Excellent. So I just wanted to emphasize, for the developer seed, this is a manual process. You can choose not to do it, and the end result will be that on your Leopard machine, it'll look like you're syncing to a brand new empty .Mac in the sky for those three data classes.

And the information's on the Leopard DVD. And it's not actually attached to the session. It's on the ADC site. So if you log in with your ADC information, it'll be there. If you upgrade to Tiger, it's automatic. And when we finally deliver this to end user customers, we will have a seamless transition. They won't have to run any scripts or anything like that. So I'm now going to demonstrate this. If we can switch to the demo machine again, please.

So what I have here is a, what I've done is I've pre-populated .Mac with a bunch of contact information and synced it up there. And some of you who were here last year may remember the People demo application. We have taken that application and it syncs using the context schema.

So we've added some schema extensions to that. What I'm going to do is-- Pull down the information from .Mac and show that not only the contact information comes down, but also the additional information. So at the moment, you can see that as previously, Address Book and the People application have the same information. And they sync locally on this machine.

I'm going to make sure I have contacts selected. So again, it's a first time sync, so I'm just going to replace what's on this computer. And the idea here is that we just go up, we get all the contact information as we usually do, but in addition there's extra information. So, oh, I've got lots of contacts already. I could go through the data change alert and see what's changed, but I'll not worry about that for now.

And whoa, so I got a whole bunch of data. And what we've done in the extension to this is that the contact information we have is name, address, usual stuff like that. And what we added to spice things up is we got the photograph. There's my photograph of me sitting in my office working hard. Got various other members of the team who contributed their photo. And the extension is we've got these alternative photographs that have come in. coupled with that data. And that's Paul on a really bad day.

So you see the schema extensions with contacts works fine through .Mac. Yeah, you should applaud. Okay. Can we go back to the slides again, please? Now, the biggest thing about a developer conference is that we try and sell you on how much work we've done to make your lives easier. So, the bulk of the rest of the talk, obviously, is going to be talking about making your lives easier.

Again, we got a lot of feedback, a lot of input from everybody saying that sync was actually a hard thing to do. We've had successes with several third parties, some very successful applications, but It's still a hard thing to grasp, and some aspects of it seem much more complicated than they otherwise need to be. So, why do we want to make it less complicated? Well, we want to make sure that you guys can write sync into your application and adopt it because, again, our users love it.

So what have we heard about? Well, it seems that there's a certain amount of boilerplate code that we have to write, and that's not that unusual. But the boilerplate code is not actually very simple. It's not copy and paste. You've got to understand what's going on. There's a state machine behind the whole sync process and being a sync client. There are lots of edge cases that you have to deal with during certain phases in the state machine, and we throw a bunch of exceptions which you have to remember to catch.

So we looked at that list and thought, well, how can we address those? This is the slide we had from last year. And there's a lot to think about when you're writing a sync client. I don't know about you, but it scares me. So to deal with this complexity, we thought we'd first of all start with the API and try and simplify things.

So the idea is try and make it simpler so that you don't need to understand as many details as you do currently. Reduce the amount of code you need to write, always a good thing. And eliminate the need for you to actually understand the whole state machine process.

So our solution is something we've called iSync Session Driver. It's a class that implements the sort of 90% solution typical sync client. And the major focus we had is that it will deal with all the control flow. So your application's job then, the code that you write for the sync client, is to just focus on the data manipulation. So all you have to do is to go grab your proprietary formatted data and convert it into the generic sync format and hand it to us at the appropriate time.

Mike, I thought you were talking about somebody called Mike. Is that better?

Okay, well maybe it's the session behind. Yeah, pay no attention to the man behind the curtain. Yeah, I'm not Mike, I'm Andy. So the other thing this does, this API, is it's adopting the more Cocoa-like convention of returning errors rather than exceptions.

Now, we do still throw certain runtime exceptions, but there are fewer to deal with. So that should make your life a little bit easier. I just want to give you an idea of what this looks like. This is the code sample from a previous Sticky's example that we shipped in Tiger. I hope you can read it.

And this is the new sample! Yeah, it's okay, it's not nothing, but... Right. What we've also added as a tool in Leopard is something to support improvements in iSync. We came across a lot of new phones that are being developed now that use SyncML. We came to the conclusion that there was going to be a way to support those more generically than we had supported phones in the past. So there's a new tool called iSync Plugin Maker, shipping on every Leopard developer DVD, and it allows anyone to develop a plugin for iSync that will support a phone.

So all you have to do is configure the plugin, you can run test suites with it, no code required. You can add some code if necessary, but the idea is to remove any necessity for you to write code. And... If anyone has any more specific questions on this tool, we'll be available to answer those questions in the lab later this afternoon. Or you can ask questions at the Q&A session. We think this is going to really help our support for new phones as they come online because basically we don't have to do all the work now. We can have other people do it. Always a good thing.

So for some reason the other thing that we've heard is that debugging sync is hard. You know, there's a client involved, there's a server involved, there's some asynchronous GUI that we throw up involved, sometimes there are other clients involved. So to try and give you a better picture on that, we've provided the SynchroSpator application.

Now up until now, this was just a sort of download available on the ADC site, so not everybody had it. And what we've done is now made it a fully supported developer tool. It ships in Leopard, and we've made some enhancements to it to improve it. And what I'm going to do is ask Paul to come up and do a fairly extensive walkthrough of all its capabilities.

So while Paul's just setting up, how many of you have actually used Sync Respector? Okay, yeah, there's some hands down here at the front for some reason, but yeah, okay, so some of you. So to some of you this will be new. Can I--another little online survey. How many people have developed a sync application and not used Sync Respector? Real programmers.

It does on Leopard. It does on Leopard. Yes, for those of you unfamiliar, we did post a version of Sync Respector. It was fully available, but unfortunately it wasn't compatible with the final releases of Tiger. So it's been a little bit difficult to get hold of this tool.

But that problem should be done with now. So over to Paul. PAUL SELIMA: Oh, all right. So I'm going to give the quick run through for those of you guys who have not seen SyncRespector before. This is what we like to call the Swiss Army knife of sync development. It does pretty much everything we can put a GUI on top of.

And as you can see here, we've got our various different windows. And I'm just going to take some time and run you through each one of these. To start off with, we have the Clients tab. This is showing every registered client. And for demo's sake, let's add that Mac to this.

Here we go, yada, yada, yada. So the interesting thing to note here is that for those of you who were able to get Sync Respector working on Tiger, you'll now notice that we have our one and only .Mac client. This is a throwback to what Andy was mentioning in that we've transitioned how Leopard machines sync to .Mac.

So as you can see here, we have our various clients. We can see where they're registered, if they have a sync alert handler, or if they have a sync tool, which are the two mechanisms by which we contact a sync client when it's time for them to do some syncing. We can have a look at what they're registered to sync, when they've last synced. You'll notice no one here has ever synced, so we have no generational number.

Actually, let's change that. Let's get address book in the game. So you can see here address book synced. Everything was a success. Everyone, you know, and there was much rejoicing. We can see here for the registration, we, well, sort of blot out there, but the schema.plist of the client registration, we can see for each entity what attributes they're syncing. So very helpful in finding any lint problems with coming up with your client registration plist.

Additionally, you can also use this to drive some syncs. So address book, for example, has a sync tool. So when we click sync up here, the sync tool will be alerted. Address book will have synced. Again, rejoice. And then lastly, for each one of these entities, we can set our sync mode. So we can set it to pull the truth, fast sync, slow sync, or refresh sync.

All these are very useful in making sure that your application can handle any kind of sync that the sync server requests. All right, so that's the Clients tab. The Truth tab, which doesn't like small screens. Darn. Let's add some more entries in here so we can have a look at these. That's my favorite contact.

And so we can see lower down here, darn, I wish I could show you the top. We have a rubber chicken up here from when demos go bad. It's not going to help, but there you go. So as you can see here, we've got, if you can see the headers, we'll have the global IDs, what kind of record it is, what generation it was added, and the generation it was last modified on. And then we can have a look at, for each application, what the local ID is for that application.

You can drill down into it to see its various properties. These, again, don't like these small table views. But the useful thing here is not only can we search by record ID, so we could pick 8C and not find it because it's going to be the only one there, or we can also search by properties.

So for example, if I wanted to find the Apple, did we get rid of the Apple card? Again, where's the chicken when you need it? Here we go. So that one-two-one card I created, you'll now notice there's one record. You can't see it, but I promise you it's there. Useless.

So we have our conflict tab here. And when there's a conflict, which is kind of hard to demo, and obviously we can't do all the easy demo stuff, so we'll save the hard stuff for later. But when there's a conflict existing, you can have a look at the various values. It's pretty much an alternative UI to what Conflict Resolver shows you. We have our history tab, which... In order to get going, we enable call history in the preference pane. And we get address book back and going.

So as you can see here, we've got a history. It's got some very useful things. We can look at the truth for any generation. So this is what the truth looked like at the time of this particular sync. We can, for each client, have a look at what changes they pushed us. We can see here that we deleted a record.

And for the Brave, we have call history, which is basically a recording of every single call that your sync client made into the Sync Services public API, including its return values, how long it took, all of those fun things. So you can see here that it pulled a change back. And we can see the various values of that.

So yeah, Sync Inspector definitely is a Swiss Army knife. We highly encourage you guys all to go out and play with it. Now, for those of you who were using this on Tiger, you'll be happy to know that we've added a new panel here, or at least enabled a panel here, which is the schema panel.

So this is another way of seeing exactly what the sync server believes is registered in terms of data classes, entities, etc. So using the people extension is a good example. This is the one that Andy used, which added those photos. We can have a look at the entities. And so you'll notice that this entity here is the contact entity because we are extending that.

And for each entity, we can have a look at the various properties, whether or not it is a required property. I'm sorry, identity property and required property. We can even see what schema it's part of. So down here for the people schema extensions, you can see that we added extreme photo, candid photo, and location.

And then more information. And then lastly, if you guys noticed it, there was the sync plans, which, while it's up, gives you a view into syncs as they occur. So we can cause that display to sync again. We can see who was involved in it, what they were syncing. The status will tell you status as it goes along. And you can also do things like reset the server to basically take yourself back to step one.

And then the last thing I want to talk about very quickly is the various preferences. Most notably, these guys. Call history, which you would enable in order to get that history tab to show you all those fun things. And extensive logging, which is basically a very extensive dump, which we often ask you guys, if you follow radars, to include along with any sync issues that might arise. Yeah, and that's Sync Respector. Thank you, Paul.

So the summary, of course, is we want you to add sync to your application. Now, before I switch to the next slide, I obviously hadn't seen the keynote like everybody else. So I was unprepared for the fact that there wasn't one more thing. So when we were, as I said earlier, we were getting a lot of feedback from developers that the process of developing a sync client was just too complicated. And they just wanted it to be much, much simpler.

So we put a great deal of effort into trying to make it really easy. And the way we've done that is to leverage one of the other technologies that we use. We use it internally at Apple a lot, which is Core Data. We expect there are lots and lots of applications out there that are already using Core Data. And we also expect that there are lots of new applications that are going to be using Core Data.

Everything. No, not quite. But maybe your next sync client is going to be very simple. First thing you need to do, well, like everything else, we ask you to register your sync client. and register your schema. But in this case, you notice that we're using slightly different calls than the usual Sync Services calls.

Second step, tell the persistent store coordinator. That's new. That's what Core Data gets you. So what we're doing here is leveraging Core Data to track changes. It already does that. It has to do that for the application. And what we require of you to be a sync client is that you track changes. Hence, we can just get Core Data to do it. Last thing to do? Well, you just sync. And there is a third step, but there is no fourth step.

So there are a number of caveats to this support. The idea is that your Core Data model is your sync schema. So this technology is useful for those people who have an application where you're using a Core Data model and it just literally maps into whatever sync schema you have. So for new applications, this is quite an interesting possibility. For existing applications, there may be some changes involved. Core Data is going to be tracking your changes, so you don't need to do any of that work in the background to support fast sync.

There's a certain amount of work that you still need to do, which you would need to do for any sync schema client. For example, when we present your data class in the dot Mac preference pane, those names have to be localized. There's currently no way to put that information into a Core Data model.

But we'll be looking at that in later drops. The big thing here is that it's not compatible with all schemas, all data classes. So it's not going to solve the world's problems in terms of the sync universe. In particular, some of the existing data classes that we ship aren't quite compatible with Core Data Sync.

Now this technology is not completely in the seed, so unfortunately you can't go away and write your six line sync clients today. But we will be providing more information and documentation later on, and you're welcome to come and to ask questions at the end of this session or at the lab this afternoon at, I think it's 5 o'clock.

So we're going to ask Paul to come up again and do a demo of this. Now, it's a little bit difficult to demonstrate. What we'll do afterwards is sort of try and walk you through the project, which is minimal. What we have here are two sample applications. The key one at the moment is Simple Stickies. That's a very simple sync client. It's written purely as a demo, although we do supply the sample code on the Leopard DVD.

This has been rewritten since Tiger to use iSync Session Driver. So here, what we're trying to do is give you a nice example of the two different ways you can use the technologies we're supplying in Leopard. So what Paul can do here is he can modify the title of the sticky, add a new one, change colors, change the translucency. You can make any number of changes in here.

And then when you save all of these stickies, you'll see them reflected in the other application, which for various reasons we've called Fancy Stickies. Hey, Presto! In Fancy Stickies, they pop up. We've got the new sticky. We've got the new translucency. And Fancy Stickies is using the very same schema as Simple Stickies because the Core Data model is compatible with that schema.

Well, let's do a bit more demo. That's more. That's more. All right. Here we go. Can't do the font on here. Now in green. So the actual mechanism by which we're showing you this isn't that great, but the things underneath, the underpinnings here are just excellent. We've got one guy just using Session Driver, another guy just using Core Data.

PAUL SELFIMAN: Yeah, so the point that this demonstration is trying to emphasize is that for certain applications, you will want to use iSync Session Driver. And in the future, for those applications that are already using Core Data and where you have a compatible schema, the Core Data Sync technology may be the way to go.

No, that wasn't supposed to be the place where you all applauded, so... Can we look at the, we'll just try and walk you through the Xcode project quickly. So the model here is the, as you can see, is the Xcode model. It's very, very simple in this particular case. Small number of attributes, translucency. The application, small number of classes. We've got a delegate, we've got the sticky that represents the entity concerned, and then some UE controllers.

But the Yeah, what Paul's trying to do is to just do a search for the project to prove that there's really not that much code involved in syncing. So that's the... It's too difficult to read, but there's a small amount of code involved in talking to the object coordinator.

Okay, well, yeah, I think that pretty much covers it. Yeah. So what we'll do now, we've got a couple of minutes spare, so all I wanted to just quickly show you was iSync Plugin Maker since we got it in the doc. So this is the-- hmm? That countdown includes Q&A.

Oh, we're back on the-- we're back on the slide. So what we'd like you to do is add sync to your application still, and Core Data is coming soon. So this is iSync Plugin Maker. It's a fairly sophisticated tool. But the take-home thing is that it's all configuration. And there are some hogs where you can add some JavaScript support. And this is for sync ML phones only, so you can't go off and write if you have an old phone that doesn't support that, it doesn't apply. Okay, can we flip back to the slides again? Yeah.

So Core Data Sync, coming soon. If you want more information on the Sync Services changes in Leopard-- John Galenzi is our software technology evangelist. We have some sample code up on the site, and as I mentioned, if you log into ADC, the Tiger Transition Kit for the .Mac sync is available there.

Some of the examples that we've shown you today are available on the Leopard DVD. And of course there's the URL for the Waverdead chicken that obviously doesn't work. We have a lab today at 5pm, so I'd love to see, I don't know whether I'd love to see all of you there, but a large subset. Thank you.