Good afternoon. My name is Scott Ryder. I am the director of engineering for .Mac, and I'm here today to talk to you about the new version of the SDK, .Mac 2.0. One thing I do want to point out right up at the front, all the sessions at WWDC are confidential except this one.

You're welcome to talk to others about what's going on in this session. We're announcing, again, a brand new feature set for the SDK today, and please feel free to talk to your friends about it. The other thing I'd like to talk about at the real beginning here is what you're about to see is the culmination of seven man years of engineering.

This is the first step on a vision or a path that we set out on five years ago, and we're just now reaching our first milestone. So we're extremely excited to be here today to be talking to you about this. It's something we've been working on, like I said, for literally many calendar years.

So without further ado, who can benefit from this? Who are we trying to build these new features for? Who is the SDK for? Well, if you're a game developer, specifically if you're doing a multiplayer game, or you're doing a game that has any kind of community aspect to it, or of course if you're doing a turn-based game, there are features in the new version of the SDK that are directly aimed for you.

If you're doing a document-centric application, you have a document that you want to move with multiple people, you have a shared document where you want to do any kind of workflow or collaborative kind of work. Of course, if you want to back up data or keep archives of different states of your document or content in your document, there are features in the SDK directly for you.

And if you're an application that requires reliable notifications, you're doing a distributed solution, you're doing any kind of distributed resource tracking or a reservation system or anything along those lines, there are features in the SDK for you. And last, if you care about inter-application communication, if you want to help build a suite so that your app can publish content to another app and that app can do more work and publish on to another app without having to have strong, formal, engineering-level ties, there are features in the kit that you can benefit from as well.

So, the agenda. I want to give you a very brief overview of .Mac for developers. What does .Mac mean from a developer's perspective? Talk about 1.0, the kit, which we announced last year. Specifically, what is it? And what are developers doing with it? This has been in the market now for a year. There's some really exciting things happening.

Then I want to talk about, obviously, 2.0, the next big iteration of the kit. Give you a feature overview, what's in the kit, what it's about, what you can build, kind of some examples of where you can go, the technology areas we wanted to open up with this version of the kit.

And, of course, we've got some really cool demos and an API review, lots of nice code sample. At the end, we'll do Q&A. But really, the whole agenda for the day is to kind of talk about what we call the DAO of .Mac, which is this idea of client-side applications and server-side applications working together so that the user doesn't have to pay any attention to it. It's just a seamless flow. And for you, the developer, you don't have to pay any attention to it. There's no overhead. There's no extra headache for you to work with a server-side component as well.

So, the DAO of .Mac integration. Why do you want to integrate with .Mac in the first place? What are some of the kind of key features it gives you? Well, it gives you a global namespace. The @mac.com namespace gives you the ability to identify your users regardless of what computer they're on, regardless if they've upgraded the OS or did a format install or they've bought another machine. It gives you a way of keeping track of that person and letting them have a consistent set of services. And it's obviously integrated with Mac OS X. You don't have to do any things with names or passwords.

It's built into that .Mac preferences panel. The kit leverages that information directly. There's no extra work for you, the developer. It gives you seamless server-to-client. It lets you work with the servers from your client without having to pay any attention to network semantics or reachability or, you know, run loops or all those other kind of things. Ultimately, this enables new capabilities. Obviously, durable identification of user.

You can keep track of people. It gives you published web with, you know, two method calls. You can get content from your local system onto the Internet in a highly scalable way. It gives you store and forward. A place where you can put content and have that move from user to user, application to application.

Ultimately, it gives you some kind of key points around collaboration. You know, and all this with full security and full access control. You know, ultimately, if you look at kind of some of the applications that Apple ships, what the .Mac SDK gives you is the ability to build those same kind of integrations, those same kind of leverages into your apps that we deliver in our apps and the OS.

So, at no cost to your application, .Mac provides some big, some big things. Obviously, access to well over half a million paying customers. The last number we put out was 600,000 public members and that was eight months ago. So, we've obviously continued to grow. We have a lot of .Mac customers and they're very happy customers.

It gives you account management. You don't have to deal with password resets. You don't have to deal with lost names. You don't have to deal with namespace negotiation. The kit does all that for you. It is highly scalable. For example, the iDisk service alone downloads seven terab-- I'm sorry, 10 terabytes a week and uploads a terabyte and a half per week of content.

We process one half a billion transactions on the back end every single week. This is a highly scalable service. We offer system support and monitoring 24/7, 365. We have a very dedicated group of operations folks and systems engineering folks that carry pagers 24/7. And if a server goes down, they bring that server back up.

We are entirely open standards based. This is very, very important. This is not custom binary protocols. This is not some hackery we're doing on the wire. We use open standards for every single service that we build and we deploy to the internet. There is no custom protocol here. What the kit does is it wraps these, and it makes them easy for you to use. But that's the big one.

Not only do you not pay for this stuff, for every new member you generate, we pay you $15. That's $15 in your pocket for as long as your application is bringing in new members. So if someone is using your app and they sign up because of your app, that's $15 in your pocket.

So architecturally, the core of .Mac is iDisk. iDisk sits in the center. All user data lives there. Alongside of iDisk, we have account management for dealing with those passwords and namespace and those other kinds of issues. And we have a suite of integration services for making sure that this can all be connected both above the line, which is where our own application servers sit.

So if you think of what a user does, this is what a user would see as .Mac. And they would obviously come in over a web browser. This is where we've been. This is kind of the traditional legacy of .Mac. But last year at WWDC, we started a new direction. We're doing a lot of things below the line.

Through those open standards, we're letting applications integrate directly with the infrastructure and the backend systems that we have in .Mac, including your app. The one thing I want to stress is the same protocols, the same interface, the same API, the same code that we use at Apple is the same code we're delivering and offering to you as developers. It's the same kit. There's no us/them. This is a we kind of opportunity.

Again, iDisk is the core. All user data lives here. The .Mac application servers access this same store as you do. It offers complete support for WebDAV Level 2, which is RFC 2518. We follow the standard right up the middle. For 2005, we've added some new capabilities. The first thing we've added, of course, is full UTF-8 support. So you can now use iDisk in simplified Chinese or Korean, Japanese, English. Basically, if you can type it, you can use it on the iDisk, and it works with both Mac and Windows.

Complete support for web dev access control list. So we're supporting the full RFC 3744 specification. This is a spec it took seven years to complete. So you can imagine it's extremely robust. It offers a very flexible ACL model. It offers user-definable groups, and it offers multiple credential support, and we're going to talk in a lot more detail about all of these.

But the key thing is, and I'll touch on this a couple times because it's very important, all credentials in .mac are first-class citizens as far as an access control list goes. There's no one credential that has a greater capability than any other. You can use them interchangeably. You can mix and match them. It's very important.

A little bit on standards. Again, they are central to our philosophy. Now, the good thing about standards is there are a lot of them. The bad thing about standards, there's a lot of them. So when we look at something, when we want to deliver a new feature, we kind of use those four measuring sticks, if you will.

The standard has to be stable, it has to be secure, it has to be broadly accepted, and it has to be compelling. There has to be something that we can truly do that's differentiating for our customers and yours using that standard. Obviously, today we support a lot of them. We support HTTP, HTTPS, WebDAV, IMAP and POP for email, XMLRPC, DNS. There's a lot of them. Like I said, standards are at the core of everything we do. So .Mac Kit 1.0.

If .Mac is open standards-based, why do you need a kit at all? Well, using these standards still requires complex network programming. There's still a lot of extra steps you have to do. Why do all the work if you don't have to? So the .Mac kit basically is built on the same high-performance Mac OS X infrastructure that Safari and all Tiger is-- CF Network, Run Loops, all of that. But we offer a simple session-style Cocoa Objective-C interface. So it's a very easy API to use. And once you've learned the way that it works, it works the same for everything we're delivering today and everything we plan to deliver in the future.

It fully supports both synchronous and asynchronous. This is incredibly important. You can use the kit to dispatch five asynchronous operations, flip it over to synchronous, do two synchronous things. The asynchs will continue to run, then flip back to async and do more work. It's up to you. Whatever your application needs, whatever call style or interaction style you want to have with the kit, it will support it. You can flip back and forth between sync and async.

It's an embedded framework. This is another very important thing. This is not something that's built into the OS. It's about a little 500 kilobyte package you deliver with your app. What that means is, as the OS continues to move forward, the kit's going to be forward compatible. You don't have to worry about something in the OS breaking or the API changing in the kit.

When you have a version of the kit and your app passes your own quality standards, you can deploy and be assured that the kit's not going to change underneath you. It will always follow with you. It will always go where you go. If your user can install the app, the kit will go with it.

So last year at WWDC, we announced 1.0 the kit. It had three core classes. DM member account. DM member account's pretty straightforward. He deals with member accounts. DM IDisc session. He deals with accessing the IDisc. Get data up, get data down. DM transaction. He actually does all the work.

DM transaction encapsulates every interaction your app has with .Mac. So when you use DM member account, or use DM IDisc session, or you use the new things I'm going to talk about, they give you back transactions. That transaction is the guy that's doing the work. He's the heart of the kit. Once you get used to the transaction style, you do something, you get a transaction, you know how everything in the kit works.

And again, fully async and sync. So a synchronous transaction, when you get it back, it's basically done. An asynchronous transaction will be in operation, and will come back when it's done. And this is all thread safe. So you can call this on any number of threads that you like. The transaction will delegate and message you back on the same thread that you called it from. So we do all that state management and thread management for you. Again, we really want to make this simple and easy to use.

The big core three things you're going to do with a transaction, you're going to determine progress. How's it doing? So if you have an asynchronous transaction in flight, you can ask it, how many bytes do you have to move, and how many bytes have you moved so far? Those will give you the answers back. And you can poll those. You can do it in a loop, do it on a timer, do it any way you like. Remember, it is thread safe, and do it as often as you need to update your user's progress.

Checking state. You can ask a transaction, is it an error, is it completed, has it started, all of those things. Or if you don't want to keep checking through a polling mechanism, you can also just register a delegate, and the transaction will message your delegate when a big state change happens. It's canceled, it's completed successfully, it had an error. It'll just call you back.

And of course, once a transaction is done, you get the result. If you were downloading a file, for example, you would call result, and the transaction would give you back his result and tell you how he did. So who's using the kit today? Well, obviously, we're using it in our own .Mac application servers.

So a good number of those half a billion transactions today that we're processing from our own servers are actually being done with the same kit we're delivering to you. It's used, obviously, extensively by Apple. Many services inside of Mac OS X Tiger use the kit to do what they do. iLife applications do, like iMovie and iPhoto use the kit.

Obviously, applications that come from .Mac, they come with your membership, like the backup app. They use the kit. We've had over 10,000 downloads of the kit in the past year. So we've been extremely excited by the number of people that have downloaded the kit and started delivering solutions. Some of the things they're doing with it, because of those 10 million downloads, we're seeing 10 million transactions come from the outside via the kit.

They're doing web publishing, a lot of good blogging apps and family tree apps and whatnot that are publishing information up using the kit. It's really simple to do. They're backing up core data files. So they do something important. They want to give the user a very simple and automated way to back it up without the user having to get involved. The kit does that for them.

Those are some of the bigger ones that are doing it. There's obviously a lot more. But one of the core things we're starting to see today is collaboration. A lot of developers, a lot of you guys, are starting to use the kit to do lightweight collaboration. One of my favorite examples is the Sims.

So the Sims 2 comes with this ability to have DNA and Sims that evolve over a lifetime, and you can build them up. The kit lets you actually share them with other people using your public folder. So you can put a Sim into your public folder, and then other users can get it down from your public folder. This whole community and collaboration thing is starting. And we took a look at this, and we kind of asked ourselves, OK, that's great. So where do we go from here? What do we do next with the kit? And that's what 2.0 is.

So the kit 2.0 is designed to be the easiest way you can add community and collaboration to your app. Those are the core goals. So goal-- we want to make internet-wide collaboration simple. We want to let your users on a system collaborate with another user on another system in five method calls or less. That's the goal-- five or less.

We offer flexible access control. Obviously, you've got to have security. You've got to have a way of controlling access. We offer a very rich publish and subscribe style messaging system. I'll talk a lot more about each of those. We offer full support for both members and non-members. Again, members and non-members. That means the host of a collaboration must be a member. They have to be a paying customer. They have to be somebody who's using .Mac to get stuff out there.

However, anyone else with a credential can then participate in that collaboration fully. They do not have to be a paid member. They don't even have to have an @Mac.com ID. So the idea is to host a collaboration, you have to be a paid member. But from that point forward, anybody with a credential the system understands, and we'll talk about that, can be a full participant. They don't have to pay. One way of looking at this is in the 1.0 days of the kit, you have the iDisk. And the iDisk had a-- you know, very central concept. There was an iDisk and there was a user of that iDisk.

2.0 of the kits lets you kind of acknowledge, hey, there's other people out there. There are other Mac.com members. There are people who aren't Mac.com members. There's groups of people. And really what 2.0 of the kit lets you do is fade the technology into the background and make it so you have this universal pipe. So data just flows from one person to another person to another person, application to application seamlessly.

This is the goal of the kit. So what's in it? So we went from three classes to a couple more. We added some new features. There are some new credentials features. We've added this concept of DM secondary user. It's a new class. These are people who don't have @Mac.com IDs, but they do have credentials the system understands. We've added this concept of DM group. And we've added DM credential. It's a new formal protocol.

We've added a new abstract base class for all sessions, in this case, just called DM session. We've added a new security feature, a new formal protocol called DM security for letting you control access to these other sessions. And of course, we've added two new services, DM message subscriber and DM message publisher. So you see we've gone from three classes to a lot richer kit.

But it still works exactly the same way. There's no difference. DM transaction does all the work. So state, including that progress, the results, they're all encapsulated in the transaction. It is fully synchronous or asynchronous. You use the same methods, whether you call it synchronously or asynchronously, result always gives you the result.

The default, of course, is async because async is the model that makes the most sense. We handle all the threading issues for you. We pull up our own worker threads. We shut them down when they're done. You don't have to pay any attention to it. So if you're writing a single-threaded Cocoa app, that's just fine. You can still use the kit asynchronously. You register a delegate. There's no threading issues for you to have to deal with at all.

So all those classes create transactions. Those transactions talk to .Mac using those open standards, and they ultimately give you a result. And they can message a delegate so you don't have to poll them. So they will simply tell you, hey, this interesting thing just happened. You probably want to go process it.

So how many people here have ever had the concept, you know, I've got this great idea, but I need a file server. I need a server that my app can always guarantee is there, that the user controls all the access to, they can let their buddies into, they can let other people into, but it's scalable and it's running all the time.

Well, that's what 2.0, the new access features give you. So a little bit on credentials, because obviously credentials are critical to how you control access to this stuff. Mac OS X has this great thing built into it. It's called the address book. And the address book gives you the ability to represent people in cards.

So if we take the idea of the address book out of the center here, and we'll just put it, because Mac OS X also has your .Mac account built right into it, right? Every logged in user has the .Mac account in the .Mac preference panel if they're a member. They have to be a member to create these things, not to use them. So we'll just replace the concept of my .Mac account is in the center. I'm [email protected]. Now, let's focus on Lynn there for a minute. Lynn is one of my favorite people. She has a .Mac ID.

And if you actually go look in your address book card, you will see a .Mac ID for either their email address or their iChat address. So you know, just using the address book API, they've got a .Mac account, and you know what that account is, and you can represent them with the member account. That's what it's there for.

So if you look through my address book here, there's a bunch of other people that have .Mac IDs, and they can all be represented by DM member accounts. This is good. Now, let's focus on Mary. Mary, still one of my favorite people, but she doesn't have a .Mac ID yet.

Well, with the new version of the kit, I have the ability of creating an ID for her that is valid across .Mac. Unlike Mary or whatever at mac.com, this is Mary@Scott. It's my namespace. It is owned to me. In fact, it's linked, hard linked to me. If you look at the kit, you use the .MacKit API to create the secondary credential. You use it to create the name, to create the password, and it's linked to my account. It's hard bound. It's in my namespace.

That means I can have a Mary@Scott, and you can have a Mary@Tom, and there's no conflict, because the uniqueness is at our names, Mary@Scott versus Mary@Tom. So if we look at the other people in the kit, I can make up credentials for all of them, and then I can encapsulate all of them in DM's secondary user accounts.

So the key thing is with 2.0, the kit, you now have the ability for every person in the address book, you can represent a credential for them, whether they have one all their own or whether you make one up for them. We strongly encourage you, the address book is extensible.

Put that secondary credential, if you make it up, in with the address book card. That way it gets backed up and it moves around as that card moves around. Put the password in the key chain. That's what they're there for. It's a great place to hold those things. So when you make up secondary credentials, put them in the address book cards and put the corresponding passwords in the key chain.

So now a little bit on groups. The address book also lets you group things. So you can have neighbors and hiking buddies and friends and family. So I just kind of organized my address book. And just like you can group them in the address book, you can also group them with a kit.

That's what a DM group is. A DM group is a collection owned by a member-- so this would be group at Scott in this case. So you can imagine hiking buddies at Scott, friends at Scott, family at Scott-- that contains credentials. And I'll say it again. All credentials are first class citizens. That means I can make a group of credentials that you control and own and somebody else controls and own. All credentials are equal.

A group can encompass any number of credentials, any number of @Mac.com users, any number of secondary users within limit.

There's a limit. Groups are global. Just like credentials are global, a group is global. And you can encompass any credential. Credentials you own, credentials somebody else owns. And you can nest groups up to three levels deep. So you can have a group of a group of a group.

So why does all this matter? Remember I was talking about bundling a file server with your app. Let's look at an iDisk. Let's start with iDisk. It's always on, 24/7, 365. It's highly scalable. Remember, half a billion transactions per week. This thing processes most of them. It is open standards based. This is not some custom file server, custom protocol. This is web dev, RFC standard. It works on Linux. It works on Windows. It works on Mac.

It has zero setup or admin. There's no software to install. There's no configuration to set up. There's no DNSs to route. It's just up and it's running. Now let's go way beyond the public folder. The public folder gave you a very, very lightweight way of doing collaboration. But now we've talked a lot about having this rich access control list support. We have these global per person credentials.

All this is no cost. In fact, not only is it no cost, we pay you $15 for every member that signs up. Sense the theme? Ultimately, this means you can ship a server with your app. Another thing that's new for 2005 is you can put content on the root of an iDisk. It used to be locked.

One happy person. So you can now put anything you want on the root of an iDisk. So you can make a folder for your app on the root. Now, so if we change the view a little bit, let's look at this a little bit differently. What if we just view that folder as a server in and of itself? Well, inside of that folder I could put a camping trip, a documents, a drop box, and a backup folder.

If I grant access to a credential, it becomes very much like a file server. So if I grant, say, read and write access to the documents folder for Darth Omen and Jane User-- and notice Darth Omen is not somebody-- it's a secondary user, but it's not one I've created. It's one George has created. Then those people can get into documents, and they can do read and write. So expand it out a little bit more.

What's really nice, this is even directly mountable. You can make this not only logically look like a separate server, but actually physically look like a separate server to the user. If you were to type "connect to" and enter in that URL, or just put it in there programmatically using the mount URL service, then it will mount on the desktop exactly like a file server. It'll get the little iDisk globe to it, but it'll have a root level. You can't go up and see the rest of the iDisk. And the permissions that you set will all be enforced by the things within it.

So this is not just logically shipping a separate server. This really is kind of shipping a separate server. You can take an iDisk now and carve it into little itty bitty pieces that make sense for your app, and represent those to your user as a section of their iDisk or as a separate server. It's at your discretion.

How it all works? Well, iDisk's expression, of course, is web dev access control list 3477 spec. You can grant any credential in the system one of the following or any grouping of the following permissions. Read. Read the contents. If you put read on a object, then it can read the contents of that object. You put read on a directory, you can read the contents of the directory.

Write. Write actually means three things. Write means create, modify, and delete. So I can make new content, I can change content that exists, I can delete existing content. A subset of write, or kind of a corollary is, you can grant just modify. That means you can't make new things, and you can't delete things, but you can change things that already exist. So if you're doing a collaborative kind of project where, say, a teacher starts something and the students are supposed to contribute to it, but you don't want them destroying it, This is one example where you might want to use modify instead of write.

and Read Children. Read Children is a special permission for directories. If you put Read Children on a directory instead of read, that means if they know the URL to the contents, they know there's a picture in there and they know the name of the thing, they can read it. But they can't actually get a directory listing. It blocks people from getting directory listings if you don't have read, you just have read children.

All these access control entities, or ACEs, are fully inherited. So you can set the ACE on the top, and all folders and all objects below it inherit that same permission. You can then explicitly, if you want, override it. So if I say, read at the top and then write only in this one object, that's one way of kind of building very fine-grained permissions.

So the three steps to setting up access control lists. Step one, get a credential. Get an identity for somebody whom you want to add permission for. In this case, it's going to be son@scott. So I'm going to get a reference to the son@scott account. The next thing you do is set access to some entity.

In this case, I'm going to give read access-- that's why I put it in yellow-- to the pages document that's contained in the documents folder of my iDisk for me. Third step-- there is no third step. That's it. Two method calls. That's all it takes. So let's do a quick demo. I want to bring up George Ma.

Good afternoon. My name is George Ma. I'm a .Mac engineer. And today, I'm going to give you a quick demo of what Scott has been talking about, how we're going to go way beyond a public folder. This is iDisk Browser, which was shipped last year as a sample app in our SDK.

And this year we've updated it with access control capabilities in .Mac Kit 2. For the demo, I've set up two folders on my iDisk, Apple and Pixar. Two corresponding groups, each with the correct permissions set up. Now, remember what Scott said about shipping a file server with your app? Well, let's see how this works. So the URL here, iDisk.mac.com, my iDisk.

Typing a credential that is part of the Apple group. And there it is. My Apple folder mounted on the desktop as a volume. I can upload to-- The file server. And of course, this being a web dev server, it means I can access it with anything that understands HTTP, such as a browser. So again, I type in the URL.

Thanks, George. So a little bit more key information about DM security, because that's how all this is done. It doesn't change the way classes work. It just adds a consistent set of methods for managing access control to each of them. What can be modified depends on the class.

iDisk lets you modify different things in other classes, which we're about to talk about. Permissions can be granted to any DM member account, any DM secondary user, any DM group. Remember the naming convention. A member account is [email protected] versus somebody@user, like somebody@Scott, son@Scott, daughter@Scott. And a group would be hiking buddies@Scott or friends@GeorgeMaw.

And it's more than just objects on iDisk. This applies to select services too. So let's talk about the real heart of the 2.0 version of the kit, the publish and subscribe. The idea is we want to power a new generation of collaborative features. We want to let you do something you haven't been able to do in a long time.

To do that, I want to go way, way back. So I've been in computing for a little while, and I remember the good old days when I had two machines. They were on the same table. They were always on. If I wanted to move data from one to the other, I did a write socket on one side and a read socket on the other side, and the world was a wonderful place. That was it. Then came this idea of, well, let's hook a couple more of them together. So the network got a little bit more complex, and the code got a little bit more complex.

And then someone said, wait a minute. Why don't we just create this big thing, a server, and we'll put all the data on there? And the network got a little bit more complex, and the code got a little bit more complex. Well, that server thing kind of caught on. And then Apple and Novell and Banyan and Microsoft, you remember there's a lot of server vendors once upon a time. And the code got more complex, and the network got more complex, and there were more people on it.

Then came this idea of, wait a minute, we have offices in the south quarter of the city and the north quarter of the city. It'd be really nice if all those file servers and users could connect and talk to each other. So the WAN was invented. And the code got more complex, and the network got more complex. And then came this thing called the internet and email, and everybody wanted to get connected. And the code got more complex, and the network got more complex.

Then the bubble happened, and WAN became a bad term, and ISP became a hotter term, but basically the same thing. But the code got more complex, the network got more complex, and then today we start moving towards universal connectivity, and now we have laptops that come and go, and DHCP, and wireless routes, and satellite routes, and hard lands, and soft lands, and dial-ups, and broadband, and cable, and DSL, and ATM, and brought in... code got more complex, network got more complex.

So that today, if you want to send something point to point, good luck. It's like communicating with a needle in a haystack. You don't know where the user is, you don't know what kind of connection you have, you certainly know an IP address, you know, heaven forbid that they have.

DotMac 2.0 provides the ability to return to the simple times. Let's make this easy. It's an API that enables communication. Fundamentally, that's what it does. It lets you send a message or an object. You can send one. You can send both. It's up to you. If Bonjour is zero configuration networking, .MacKit 2.0 is zero networking networking. You don't pay attention to any aspects of the network. You don't worry about IP addresses. You don't worry about daemons or server processes.

Now, for the three people in the room that get the joke, the idea is this is not new stuff. Like I said, we try to leverage open standards everywhere that we can. In this case, we're leveraging something called message queuing technology or publish and subscribe message queuing technology. But we're ratcheting it up a notch. Scale with zero admin. Most message queues are kind of 10,000 user systems. We have a couple more than that. So this is a message queue that runs at our scale. 600,000 is the last public number, and we're growing well beyond that.

It provides in-order delivery. If you send messages 1, 2, 3, they will arrive. 1, 2, 3. It offers you named endpoints. You don't send a message to an IP address, you send a message to a person. The system guarantees that it gets to that person. It offers store and forward, so that the client machine doesn't need to be on.

If it's not on, we'll hold the message until the machine is on, and then we will deliver it. It offers a push model, even through a NAT. So the idea is the message delivery latency time is somewhere under sub-second to get that message from point to point, plus the time it takes to actually transfer the bits. So the connection setup, if you will, is sub-second.

It even offers launch and receive. That means your app doesn't even have to be running. Messages can arrive in the background, and when your app is run, the user will pick them up. Or if you wish, you can register with the system so that if a message arrives to your application, your application will be launched, and then the message will be delivered. Or a tool for your application can be launched. It's up to you. So no background demons, no extra processes, no cron jobs. All that's gone.

and a whole lot more. It's secure. It's robust. But the basic idea is really simple. I have two systems. On the first system, I want to send this thing, in this case a picture, to this other person. The other person said, "Yeah, I want to subscribe to that picture's thing." And the picture flows from one machine to the other. That's not just slide sample code. That's valid pseudocode. That's really what it is. Remember I said five or less. It technically is down to about three.

So a little bit on publish and subscribe, because it makes sense to have some background. At the top are applications, or sometimes called channels. It's the root of the hierarchy. The key thing is one application can see another application's messages. They're not hardwalled from one another. This is core for cross-application communication or collaboration. If you have a pictures app and somebody else has a pictures publishing app, they can work together without the two developers having to jump through any hoops. You can see each other's messages.

topics, organize message. They're an organizational unit, much like a folder. And inside of those topics go the messages themselves. And a message can have three things. It can have a message. It can have a payload, a typed payload, very important. And it can have meta, any kind of meta information about that payload or about that message. It can have one of them. It can have all of them. It just can't have none of them.

What can you build? Some very simple things? Well, you can do any casting. You know, podcasting is very hot right now. But you can actually use this kind of as an infrastructure to do an any cast. Imagine I have a system. And on this system, I've got a container. And inside that container is stuff: media, text, pictures, whatever else.

I have a bunch of other people that I want to work with, another system. In fact, a bunch of people that have all said, yeah, we want to subscribe to this particular channel. In that case, they say, subscribe to the Ryder Family News. At that point, when I publish something, they receive it. Another key point about our messaging technology, it's bidirectional, meaning if I publish something using that same channel, they can publish back to me. So it's a two-way street if you want to enable it.

What else could you do? Imagine workflow and collaboration. I have this object, this thing that I'm working on. Now I want to send it to somebody else who is or maybe is not using my app, but they're using an app that understands my data type, a JPEG, an RTF, a sound.

Well, in that case, you simply would publish that message, that object as a message to another person. They can then do whatever it is that they want to do to it, including, remember, it's bidirectional, so it could come back to your app. That person could then turn around again and publish that out to another person who does even more things, and that's bidirectional. So you can imagine, you can start building these either workflow chains or approval chains or distribution chains where data starts moving from app to app very, very simply.

So what else could you do? Well, how about notifications? Imagine I have this one system up here. He has, in this case, I'll represent it as a book. He has this thing that he says, "Hey, I've got this. It's available." So he publishes a message out to all his buddies saying, "I've got this new thing." And his buddies say, "Oh, yeah, I want that." So he sends a message back, "Yeah, I want it." So does this other guy. He sends it back.

But because of the in-order delivery, you know which order the messages arrived or which order they were published in, so you can say, "Okay, the first publisher wins, and he gets the rest." You do event parsing. You have an event that happens here. You want to track its flow.

So how do you do this? Well, DMMessagePublisher is the root for publishing messages, obviously. He generates and manages message topics, and he actually publishes the message themselves. He conforms to DMSecurity, too. We'll talk about that. Message publishers generate topics. Giving an access to a topic. So if I let George Ma or Ryan Parks into a topic that I've created, an invitation is sent.

And the invitation is the core of the security model. You don't receive messages from me until you've accepted my invitation. And an invitation, by definition, can contain no payload. It's one bit. It says, "This person's offering something to you. Do you want to take it or not?" At this point, the DM topic contains the messages, and obviously he manages the messages.

Messages themselves can contain data, and they generate transactions. So the flow can look a little bit complicated. Let me show you the code, because it's actually a lot simpler. In this case, a member must host the topic. So in this case, I'm going to get the member account out of the system preferences on the local machine. That one call pulls the password, pulls the account name from the .Mac pref panel.

I get a DM publisher session, because the DM publisher session is the key. He does all the, you know, sets everything up. I create a topic and add a message. In this case, it's the obligatory greetings topic with a message of "Hello, world!" I then set access. I give another .Mac member permissions to get into this. In this case, I'm going to grant access to Ryan and George.

How do you get them? What's the other end of the equation? Well, get a DM message subscriber. He manages your subscriptions to topics. There's a new kind of delegate called a subscription delegate. He handles the obvious things, like when new messages arrive, he has sent a message saying -- his method is called that says there's new messages available for you, new topics.

Of course, he gets DM topics. They contain and manage the messages in question, and the messages contain the transactions. Very important point. By default, when the kit tells you you have a new message available, it has already been downloaded off the net and cached locally. That means you don't have to pay any attention even to network latency.

When the kit says there's a new message available, it's available on the hard drive. If you say, "Give it to me," it'll come back, whether it's a one-byte or a five-megabyte message, it'll come back instantly because it's already cached. We strongly encourage you to use this behavior because it just makes your UI. You don't have to worry about blocking or network delays or reachability or anything else. It's just there and it just works.

There are a couple application cases that we can think of where you wouldn't want this, so you can turn it off. But it's on by default. It will always download the whole thing and then tell you about it afterwards. Meaning if your app is launched because new messages have arrived, they've really arrived. They're already on the system. You're ready to go and start processing them and doing work.

The code? First thing you do, again, get a reference to the local Mac user's account. That's the thing in the system preferences panel. Create a subscriber session in a delegate. Assume the delegate option sets up and he has to conform to one key message, one key protocol, if you will. But that's what it takes to set up a subscriber. How do you receive new messages? There's one method you have to implement. Topics have changed. You will get an array of topics that have new messages available in them.

The full code for this would be, I'm going to write a simple iterator. So I'll get one for the current topic and one as an NS enumerator for the array. walk through the array, pull out the newest message. You should look deeper. This is sample code for a slide, but newest message will give you the last one, but there could be more.

From that message, pull out the message string, pull out the payload, pull out the type. Key thing, type. When you put a payload in, if you want to let your application work with others, use standard types. And Spotlight has done this great thing of pushing in the internet both, pushing down standard types.

Pictures are typically JPEG, but you could use TIFF or anything the system understands. For types, just use the file extensions, you know, .html, .xml, .plist, .jpeg, whatever makes sense. Pass that type along. If it's something you want to keep private, keep it in a private type, you know, .myapp. It's up to you.

Then hand it off to a controller to go do something with. Process the message string with the particular payload of that particular type. Type is key. Type is how you do inter-application communication. You let users build suites of applications without you having to work with the other developers.

As long as they publish a JPEG that's of the right format and you understand a JPEG of the right format, your two apps can subscribe to each other's messages and work across the message queue with no extra work on your part. So enough talking. Let's see some cool demos.

Hi, I'm Ryan Parks, and this is Chris Sharp. We're going to show you some of this publish and subscribe technology in action using a little application called .MacKitTiles. And basically how this works is each one of these tiles is an NSImageView that you can drop an image to, and there's a publisher and a subscriber in the tiles app. And each one of these tiles represents a topic. You heard Scott mention a little bit about the topics.

And the thing about a topic is it's a queue that you can publish messages to. You can subscribe to it. It's all in one. So basically Chris is viewable on my computer through this little remote view. You see him. And we already have one image published, but he's going to publish another one.

Pretty cool stuff. And this is a great example of taking an app like TextEdit with not really much network capabilities at all, nothing to speak of, and turning it into this powerful collaborative app with a relatively small amount of code. You just create a publisher and a subscriber. And actually, in this case, it's just a subscriber in TextEdit. And voila, you've got this great collaborative app. And we hope you have a lot of fun with this. Thanks very much.

So it's always very important when you're doing anything on a network to talk about security. I want to give you kind of the high-level review of our security model as well. So on this one on the left, we have myself. I'm going to publish some stuff into my topic. I create the my topic using the DM publisher calls. I then use the DM security protocol to grant access to Ryan Parks.

The minute I do that, that automatically generates an invitation. So an invitation is then sent to Ryan Parks saying, hey, [email protected] is offering you this new topic, the-- I forgot what I called it-- the my topic from the My Great App. The invitation's a programmatic way of saying, what do you want to do? Ryan has two choices.

He can accept the invitation, basically just subscribe to the topic and off he goes. Now messages will be delivered to him. Or he can just ignore it. If he ignores it, then nothing happens. There's no queue built. There's no endpoint built. He never hears about that topic again. So in this case, obviously, he's going to subscribe to it because he likes his job.

Accepting invitations is really simple. You get a transaction. That subscriber will call you back and say, hey, there's some new invitations you've received. Then you simply walk through and accept the ones you want. So in this case, I can say, give me the last object. You get an array of all the invitations. Give me the last one. Now again, you should look deeper, because there may be more than one. But for sample code on a slide, last object is fine.

Then ask some controller, do you want to accept this invitation? Notice, invitations are programmatic things. They may make sense to represent as UI to the user. They may not make sense to represent to the UI as a user. For example, if you're doing a distributed kind of app, where you want to move event parsing or event back and forth, then probably you want to accept the invitations programmatically. Just decide, this is something I want to accept.

Versus if you're a collaborative app, say like text edit there, you'd probably want to put something in, hey, Ryan is offering you a subscription. It's coming from this app, and it's JPEGs. Do you want to accept this subscription? So you can do it either way. It's up to you.

In this case, I'm just handing it off to some controller to make the decision, yeah, I want to subscribe to that. If that's the case, you say subscribe to topic, and you're done. You now will receive messages on this particular queue. It will follow the launching behavior you've configured. It will follow the pre-download or pre-caching behavior that you've configured. Valid code.

So once I accept that subscription, I can start publishing, obviously, at any time. It doesn't matter. And those messages will flow across. They will come from my system to his system. All the latency and on and off and reachability, that's all handled. If I want to let back publishing happen, I want to not only give messages to Ryan, I want to let Ryan give messages back to me on the same topic, you can do that.

Using the DM security protocol, you would grant Ryan access to my topic. So I'd create it, it's my topic, obviously I have access to it. Granting Ryan access to read gives him the ability to get messages. If you give him read and write, then he can obviously put messages back, and messages will come back to you.

Key thing: only the sponsor can grant this additional back publishing privilege. If I give write to Ryan, Ryan can't turn around and give write to somebody else. Only the subscriber, only the person who's the sponsor can control who can put what into the topic. But, in this case, I'm going to give Ryan back publishing permission. Ryan uses the same message publisher calls as if he created the topic, and the messages come back to me.

And of course, anyone can unsubscribe at any time they like. Their infrastructure connections are torn down, and they no longer receive messages on that topic. And if they want, they could go back again at a later date and resubscribe to the topic. It's up to them. So, what can you build with this? Well, it's very well suited to obviously different applications that need to work together.

Because of those tight payloads, you can build solution suites. Either you can partner with other developers and do a marketing bundle on your own, or you can let users do it independently of you. It's up to you. Obviously, the suite can be all from a single vendor, or you can mix and match.

Ultimately, you can also use these as components in the workflow. I produce images, you package those images into documents, he takes the documents and hands them off to a printer, and they get printed. The publish and subscribe messaging system can move that message along. If you want to move data from one user of your application to another, picking up and turning in assignments. In the education world, a teacher could publish an assignment. The app would launch and all the student systems saying this new assignment has arrived.

They go do whatever it is they need to do, take a test, whatnot, and publish back to the teacher's machine. Workflow and approval chains. Is this image good enough? No. Change, change. Is this image good? No. Change. No. No. No. Maybe. You can do all those kinds of things.

Assembling lots of dynamic parts into a whole. You saw the simple change we made to text edit. Add the ability to subscribe to it. You can build apps now very simply where it's an amalgamation. Content comes in from a bunch of different apps, written by you, written by others, that you assemble into some whole that has meaning in your space. Multi-user, multi-way collaboration. Imagine 10 years ago, the hot topic was shared whiteboards. This is kind of the uber shared whiteboard, because now you can start mixing and matching content from a lot of different places.

Ultimately, we know you can do some really, really cool things with this. The examples we put up here are very simple ones to kind of whet the appetite. But imagine what you can do with an app where you don't care about the networking anymore. You know the network will get the data there. It'll arrive.

It'll arrive without you having to do any headaches or extra network level programming. When I started coding a little while ago, networking was really cool. But boy, was it a pain in the tail. Sockets is powerful, but Sockets is not friendly. Two method calls in Cocoa, that's kind of friendly. I have an image, publish the image.

This isn't a perfect fit for everything. It doesn't solve all the problems. Large groups. This has a finite number of endpoints. It's not designed to be the thousand to one publishing system. This is designed for letting groups of friends or larger, a little bit larger groups work together. But this is not how I would deliver content to every person in this room. It's not what this system is designed for today.

High transaction or high message rates. If you try to send things too quickly, you could get back KDM service busy. It just means you're trying to put stuff in, do it quicker than the queue can accept it. Now, we're still playing with where the right numbers are, but the bottom line is, if you're doing stuff in a reasonable manner, like a message or two every ten minutes or every minute, or maybe even half a minute, you'll be fine. If you're trying to do ten messages in a second, you're going to get back KDM service busy. If you get it back, simply just wait a little bit and try sending it again. It just means you're sending too quick.

This is a centralized service, though. So if you kind of look at the spectrum of networking technology, on the extreme left, you have burn a DVD, put it in a FedEx envelope, and send it off. Pretty reliable, but not the best latency in the world. Latency is measured in days. The other end of the spectrum is the first person shooters, you know, Halo or games of that nature, where latency is measured in the sub-milliseconds.

This kind of sits somewhere in the middle. If a file server is a perfectly acceptable way, make changes to a file, save the file to the server, this is a perfect fit. This is that kind of scale, that kind of latency. Obviously, I didn't take it all the way down to the days because our latency isn't that low. But we're very, very close to the way emails, instant messaging, file servers kind of work from a network latency perspective. We're not a first person shooter. We're not designed to handle messages at that rate. That's not the purpose of the kit today.

Situations where messages are completely transitory. Remember, all messages are stored centrally. This is important because the store and forward. If the machine that it's sent to isn't on, we have to hold it in the center for a little while. So you don't want to say, this has changed.

It's changed. It's changed. It's changed. It's changed. It's changed. You'll fill the queue because all those messages get held in the center. You want to keep this at the object level. This is not a status protocol as much. You can use it that way if you're careful, But it's really about an object. This data's changed, and here it is. Here's the data.

There's a maximum capacity in that center. The queue has a depth, a finite depth based on quota. And it doesn't offer anonymous support. So this is not a P2P system. I can't send something to anybody. I have to send to Ryan, to Chris, to George, and to Mary.

I can't send to anybody who wants to subscribe to it. Doesn't offer that anonymous endpoint. All endpoints must be named endpoints. And they obviously have to accept the invitation. So when you grant access to somebody, they get that invitation. They accept that invitation. And then they get messages. They don't get messages until they accept the invitation. So to wrap it up.

We've talked about a lot of stuff. Tomorrow there's a lab in, I believe, it's the second floor application lab one. For three hours from 9:00 to 12:00, we will have the majority of the .Mac engineering team available to answer your questions about the kit, about .Mac in general or otherwise, if we don't get to them today.

We'll be happy to give you architectural advice, how to play with stuff, how this could integrate to your app, what's the best way to make it fit, and of course, answers for any burning questions that come up. Right after we left the room, you go, oh, I wanted to-- tomorrow, 12:00 to noon.

Or I'm sorry, 12:00 to noon. That's good. 9:00 to 12:00. So how do you get this kit? It's an embedded framework you can ship with your app. Remember, this doesn't come with the system. This is a little package that you deliver with your application. It's available from developer.apple.com.

use a unique creator code for your app. Something we learned last year. All of our sample apps use the four dashes as their creator code. Don't use the four dashes in your application. It doesn't give you the best quality of service. The system uses those creator codes to kind of do a guaranteed quality of service.

The sample code gets the absolute lowest priority. So don't use that code. It's real simple. There's a simple website you can go to. Your app doesn't even need to be started. You don't have to have a single line of code laid down to get a creator code assigned.

Use that creator code. It's a four-digit code. Put it into your app. That will give you the best experience with the kit. Don't use our four dashes. They're just for the sample code. The latest release will have the .mac kit framework, all the documentation, all the sample projects, including every demo that you've seen up here today.

and .Mac Kit 2.0 preview in Universal Binary will be available July the 1st. So we're almost there. And in the lab tomorrow, we will have early builds of the kit that you're welcome to come play with. And with that having been said, again, I'd like to thank the .Mac team. There are members of this team that have been working 70 hours a week for the past year to get to this point.

And ultimately the-- whoa, that's neat. The formula we can't see. So we know how to get the kit. The formula that this is designed to enable fundamentally, you take Mac OS X Tiger, you add to that your application plus the .Mac SDK, and you get to this networking nirvana, this point where client and server blend together.

The user doesn't have to pay any attention. You can send messages from one of your apps to another one of your apps with two lines of code on the sending side and about three or four lines of code in a single method on the receiving side, and it gets there.

And with that having been said, a couple contacts for you. Xavier is our WWDR evangelist. If you have questions, reach him. Molly is productmarketing in .Mac. So if you have marketing questions you'd like to ask, that's a good place to put them. Two email addresses for .Mac kit. Bugs. Use the bugreporter.apple.com website. Don't send bugs to these email addresses. That's not what they're for.

The .Mac kit feedback is API suggestions. The kit's developer preview. So if our API is a little not quite perfect, send us feedback. Let us know. If there's a service you want to see in the kit, let us know. This is a direct pipe into the engineering team. It's a great way to kind of get feature requests into the kit.

.Mac zen is if you're doing something really cool, you've got that yin-yang kind of thing going in your app, and it's really cool and differentiating, and you want to make sure we know about it so we can possibly-- co-marketing or whatever else-- send it to .Mac zen. It's a direct pipe into the way-- way of getting things up there so people know and we know that you're doing cool stuff out there.