This is the iCal Server Platform. I hope you're in the right room. My name is Wilfredo Sanchez. And I am the server engineering lead for the iCal Server at Apple. So what are we talking about? We are talking about Apple's calendaring solution for Leopard. It is finally here. We've been listening to you and finally we've managed to deliver something that you can use.

We've gotten a lot of feedback that this is something that's very important for a lot of It deployments and to developers that are trying to like adopt a platform and get it into the back office. So here we go. Our server is based on open internet standards and the whole point of that of course is that it will interoperate with clients on other platforms and eventually servers on other platforms as well you can deploy our servers on other platforms as well because it is a portable server.

Just as a note our server and clients both iCal and iCal Server are actually pretty far ahead of the game in terms of adopting this standard that being CalDAV which I'll talk about. There are other clients out there in the world that do some of this stuff but most of them are just getting off the ground. And we've actually got 100 percent of the specification built into our clients and server.

And of course our server is open source which means that if there's anything it doesn't do for you, you can of course either customize it as you see fit or provide us with feedback or file bugs directly in our bug tracker and we'll talk about that at the end.

So what you'll learn today is what the status of the current standards? There are actually a lot of standards in play and we'll get into that. What are the features of the iCal Server? What is it exactly going to do for you? We get into a little bit how it actually works and how can develop for it.

So getting started what's the standard picture actually look like? We've got something that's going to end up looking like a calendaring solution. So first up is data format called iCalendar and that's specified in our RFC. And it basically tells you something about how data for calendaring events looks like. On top of that there's another specification called iTip which lets you make requests about calendaring such as is somebody available for a meeting.

And in order to make any use of that we need some kind of a transport and HTTP as we all know uses a very important protocol for moving data around on the internet and it plays well in a lot infrastructures. So we're going to take that and we're going to on top of that leverage XML and WebDAV and WebDAV ACLs in order to provide a way to publish data on the server. That iCal and Tiger of course made a pretty good use of WebDAV in order to give you public subscribed functionality.

But in order to get something more we need a little bit more sauce on top of that. And to start with we need an access protocol for how to get calendaring data and how to write to a server in such a way that the server can maintain the consistency of the data and force semantics and let you do things like searches for data that's interesting to you.

And on top of all of that is a scheduling specification that's going to let you say invite me to a meeting or, you know, update the status of a meeting and fan that out to all of the people that are participating in it. So it's a -- give you the run down on exactly what's going on with standards, Cyrus Daboo is one of the authors of CalDAV spec and is my partner in crime on building this server. We'll give you the scoop.

Okay thanks, Wilfredo. I'm Cyrus Tabu I'm the server engineer on the iCal Server team and I'm here to talk to you or give you an update about the calendaring standards status and Apple's involvement in that. We're also going to get into doing a couple of demos as well. So you're going to see all of this stuff in action too.

So as Wilfredo mentioned iCalendar is really at the core of the calendaring Standards. The iCalendar specification is defined by the IATF into the engineer task force is Document RSC2445. And it's a very basic text-based format for calendaring information. You can describe things such as events and tasks or to do items. You can have a log on those events and tasks. You can describe time zone information so that you can encapsulate daylight savings times rules.

And you can do things like specify recurring events in very simple patents or you can do more complex recurrence where you might have exceptions to recurring events or complicated patents like the last day in June and things like that. Now, along with iCalendar we have iTip which is a transport independent protocol that defines how you exchange calendaring information in order to do scheduling. So basically what iTip does is add a method property which basically describes a set of verbs that define how scheduling should take place.

So a typical operations are just publish an event to a group of people or send out an invitation which is the request method and then the attendees can reply to that stating whether they are going to attend or whether they are going to decline the meeting or even propose an alternative time for the meeting. And in addition there are descriptors in the iCalendar data that let you define who the organizer and the attendees are within the scheduling process. So these roles actually get to be important when we look at CalDAV.

Now, iCal and iTip together they provide the core standards for internet calendaring and scheduling. And they are supported by many products today. Lots of products out there that they even use propriety standards for actual calendar access and calendar data access. They allow you to do iCalendar in important iCalendar data or even send iTip messages in the form of E-mail messages in order to do scheduling through E-mail.

These standards are actually almost ten years old now and there's actually an effort going on in the ITEF to do some revisions to the standards. And the primary goal of these revisions is basically to fix up some inconsistencies and some problems that have been spotted over the years.

And also to simplify a few issues that are known to cause interoperability problems. So again the key focus here is on interoperability for clients and consumers of calendar data. So let's move on to CalDAV. And as we've saw a short while ago CalDAV is built on WebDAV technology, WebDAV access control, iCal and iTip.

The key thing that CalDAV does is define very specifically how calendar information is stored on a WebDAV server. So you could just use a regular WebDAV server and throw events up there and -- it a calendar server? Well sort of. But what we really want to be able to do is to achieve interoperability between different clients.

So different clients need to be able to agree on a schemer, if you'd like, how that calendar data is stored on the server And what CalDAV is does is define very explicitly how calendar data is stored on the server so the clients have assurance that they can find that information quickly and they're able to manipulate it in very Interoperable way. In addition it also defines how iTip is used to do scheduling on a CalDAV server.

The key thing that CalDAV adds to the WebDAV protocol is a new set of methods HTTP methods for creating a calendar. It adds reports which are basically a means of doing queries against a calendar stored. So CalDAV for example implements a time range report which would let you find all of the events on your calendar for this week for example.

And of course it defines key access privilege concepts that are needed in calendaring. So for example in the calendaring space one of the things you want to be able to do is allow people to see your free busy time but not actually see the details of the specific events that you have on your calendar.

So CalDAV defines a special WebDAV access privilege to enable you to control that piece that control over the access. CalDAV is actually split into two specifications. The CalDAV access specification is now complete and published in March as RFC4791. The CalDAV scheduling specification is nearly complete and we hope to actually see that submitted to the IETF in the next month or so.

Let's take a little bit more closer look at the CalDAV data model. So we're going to have a calendar server which is a WebDAV server at the top level and we are going to need a place to store our calendars so we have a calendar's collection and below that we are going to want to discriminate different classes of users on the system. So we're going to have separate collections for users, groups and locations.

Within each of those top level collections we are going to have collections that refer to the individual's participating in that particular class of user. So in this case we have three collections for Cyrus, Wilfredo and Chris. And these are basically the calendar home directories if you'd like for each of these particular users. So within my calendar home directory I can actually go ahead and create a set of calendars, I also have an in box and an outbox collection which actually take part in the scheduling process. And we'll talk about that a little bit later.

With each of my calendar collections, that's where I actually store the events for that calendar and remember each -- this is basically a fundamental level which is just an HTTP server. So everyone of these resources, everyone of these events is a addressable via URI. You can go in with Safari and browse this entire hiearchy assuming you have the appropriate privileges to drill down into this.

The other thing that we need to be able to do on the CalDAV server is define a way to maintain information about the users and groups, et cetera that are actually participating in the calendaring operations. So the WebDAV access control specification defines its concepts as principle which is basically an entity that is taking part in some kind of WebDAV operation.

So again to maintain the information about these we have a principles collection on the server and again we have similar users groups and locations collections. And then for example within the users collection we will actually have -- here we go we will actually have principle resources that actually represent the individuals that are doing calendaring operations.

We can have groups which obviously represent, you can create groups of users that are can be manipulated and managed through access privileges, et cetera. And then the other piece of information you typically need a location. So you need to be able to book meeting rooms as part of your scheduling process. So again we maintain that information on the server as well.

Now, how does scheduling actually take place on the server? So here's a quick example. We have an organizer meeting and we have an attendee to the meeting. So the organizer through their CalDAV client which in our case is going to be iCal... What they are going to do is they are going to create a scheduling request, a meeting in their calendar and thy are going to add some attendees and the client is going to post that request to that organizers outbox on the CalDAV server. Now, the CalDAV server is going to spot that information coming into the outbox. It's going to pick that up and it's actually going to deliver it to the in box of all of the attendees that are listed in that particular event.

Now, each attendee they're monitoring their in box and they can pick up that invite as a notification and they can process it in the appropriate way for them. They may choose to accept the meeting or decline the meeting. And what they would typically do is change the status and book the meeting on their main calendar and they'll send a suitable reply back to the organizer. And they simply do that by pretty much by the same process.

They take the event schedule request should you reply and they deposit it in their outbox, the server picks it up and puts it back in the organizer's in box, and the organizer can then update their status information based on that. And to see what this would look like in the case of multiple attendees we basically have this scenario where you have a fan out of the scheduling information from the one organizer to all the attendees in the meeting. And each of those replies back to the organizer and that information is then correlated and aggregated by the organizer.

So where are we with CalDAV? There are still some key elements of the calendaring and scheduling infrastructure if you'd like that we actually want to complete. And one of the key pieces of those is really the server to server protocol. One of the key things we want to be able to do is actually do federated free busy information and custom scheduling.

So CalDAV as it stands right now justifies how you do calendaring and scheduling within a single organization or authentication domain. What you want to be able to do is to actually allow you to invite people from other companies or universities, other organizations or look up people's free busy time in a similar and easy fashion. That work is just beginning to spin up right now. Now that we've got to the end of the CalDAV access and scheduling specification work.

Now, one of the things that we've done in iCal server based on our experience of actually using these protocols is that we found there's a need for certain extensions to the protocol to aid userability on the client side and to improve performance on the server side as well. So we've actually gone ahead and put together a set of extensions and the specifications for most of these are actually available on our open source website which Wilfredo will show you about a little later on.

So we have a masked UID extension that improves the free busy user interface in a client. We have a C tag extension which basically allows a client to do more efficient polling of the server and that obviously improves the server performance as well. Then the next three I'm going to go into a little bit more detail proxy users, office hours and drop box.

So let's look proxy users. So one of the key functionalities in an enterprise calendaring and scheduling system is the ability to delegate to someone else the responsibility to manage your calendar. So often, you know, very busy managers at a company need their assistant to handle their schedules for them. So we need some way implement a similar functionality in the iCal server iCal client infrastructure.

So the way we do that is by providing groups of principals on the server that allow you to manage these proxy user groups. And the key thing to this is that rather than having the client manage access privileges directly, they actually simply get to manage group membership instead. So the server actually provisions the appropriate privileges for each of these proxy groups automatically. And all the client has to do is change the group membership.

In addition to this it's also much easier for the client to actually look at the group membership list to find out who you are a delegate for or who has chosen you to be a delegate for them. So it's much easier from a managements stand point as well.

In our case what we actually do is define two group principals for each -- each primary principle on the system. So I can have a group of read only delegates, people who have read only access to my calendar, they can see my calendar information but they can't change it and they cannot schedule on my behalf. Then there's a read write group and those people are actually able to change calendar events on my calendar and they can also do scheduling.

The proxy groups are given read access in the appropriate way by the calendar server. So if we have a quick look at the data model for this we saw the principle hiearchy before and we had principle resources for each of the individual users. What we now do is actually make those principle resources a collection and within each of those collections we have these group principle resources representing these two new group principals. And each of the user principals will have their own set of groups like this. So it's just a case of managing the group membership.

If I want to give Chris read only access to my calendar hiearchy I can just add Chris to my read proxy group and he automatically gets access to my calendar home directory and all of the calendar information within that. So end users have actual control over this through their clients rather than a system administrator having to go in and manage that information. So that empowers the end user in terms of this proxy capability.

The next thing we want to talk about is office hours. Again there's a need in an enterprising environment for you to be able to specify when you are going to be in the office and when you're likely to be out of the office to aid people in terms of scheduling. We have an office hours specification. This is built on a via availability component which was actually defined nine months ago and is actually an extension to the iCalendar data format. And via availability allows you to describe office hours information inside iCalendar data.

The key thing about this is that unlike the free busy components iCalendar carry defines you can actually define reoccurring periods of free time or busy time through via availability. You can also include exceptions so you might be out of the office for one Wednesday afternoon and again you can put that information in that manner.

Now, the via availability component is actually managed by storing the via availability component on your in box. So that means it will actually take part in your free busy lookouts. So when someone looks up your free busy information via availability data will actually be consulted by the server and will be used to form the free busy information that goes back to the client.

Now, iCal actually provides a new way for you to specify your office hours information as part of its CalDAV account set up. So they provide two modes for doing that. There's a simple mode where you can just specify start time and an end time for week days, Monday through Friday. And then there's a more sophisticated mechanism where you an actually specify start time and end times for each day of the week independently of each other.

And when you put all of that together, and you actually do a free busy look up, you'll get an iCal's new availability window that you see here. You actually see unavailable periods on the left hand side and the right hand side of this window and that actually represents the out of office hours if you'd like for each of these individual people. So you can see the different people here had set up their own different office hours as appropriate for them. And that information is displayed as part of this free busy look up and you can make appropriate scheduling decision based on that.

The other thing we want to talk about is drop box. Again in an enterprise environment there's often a need for you to send attachments as part of your event information. Now, you could embed the attachments in the iCalendar data but that's not very efficient from a server standpoint because you end up uploading that data every time you make a simple change to the event itself. So if you just correct a typo in the title, you end up having to upload that data each time due to the way the inline attachments work in iCalendar.

So a better approach is to actually store these attachments externally in a separate collection on the WebDAV server and provide a pointer to those inside the calendar data. So that's pretty much what those drop box functionality is except in this case the way we do this is that the server actually provisions drop box collections for each user in a way that it's easy for the client to discover where they are and to manage and manipulate those collections and set up the appropriate privileges.

Again one of the key things here is that the client will create a drop box collection for each event that is going to add an attachment to. And specifically it's going to set the privileges on that collection to match the list of attendees on that event. So only the attendees of a particular event are able to access the attachments that are related to that event.

And the other thing that we're able to do with this is that changes can be made by anyone who's a participant in the event. So it's not just the organizer who can add attachments but the attendees can also drop their own attachments to their drop box and modify existing attachments. And that information gets pushed up and notification sent to the other parties to the meeting as well.

So a quick way to look at this we have an organizer that's going to send them a meeting out to several attendees they send that meeting out in a regular way but they also drop their attachment into their special drop box collection. All of the attendees and the organizer have read access to that. So they can see that attachment in the drop box. At some later point the attendees may choose to add their own attachment and they can simply do that by dropping it into the drop box. And these notifications go out to all the participants in the event.

So that's actually show a demo and see some of these features operating.

Okay. So here we are and I'm going launch iCal. And we have a typical iCal window here. And I've got this single local calendar on this in iCal but there are no events here.

What I'm interested in of course is my servic calendar information. So I'm going to go into iCal preferences, there's a new accounts tab here. And I click on the plus button and I can add a description from my server, I can add to my user name and my password.

Now iCal is very much integrated with the MacOSX server infrastructure. It's actually using OpenDirectory to go out and get information about the calendar users on the system. So in this case it's actually going to go to the directory and look up my calendar server information so it can automatically correct this account for me.

Now, and all I need to do is enter my user name and password. So I've done that I can click the add button and it's actually going out, it's created an account for me and it's actually gone to the server and pulled down the calendar information from the server.

So here you can see my calendar for this week. And again that's coming down from the calendar server. I could go to another machine and do exactly the same process and I see exactly the same view. I could movie events around in iCal here and it's pushes those changes back out to the server almost immediately.

So again another client will see those changes reflected as well. So here we are really leveraging the benefits of the client server architecture for managing calendar dates in this way. Of course one of the key things we want to be able to do is scheduling. So let's actually see an example of that. So what I'm going to do now is I'm going to create an event on Thursday here.

And I'm just going to call that meeting. Now, I want to invite a few people so I want to invite my colleague Wilfredo. So I can start typing his name and again iCal is using OpenDirectory to look up calendar users on the system. So it can do all the completion of that.

So I can hit return. I also want Chris to come along to this meeting. So I can hit return here and now I hit tab. Now, what iCal is actually doing in the background at this point is going out and looking up each user each of these attendees free busy information.

If we actually take a closer look here you'll see there's a little icon with Wilfredo's name which actually indicates he's busy during this time slot. So obviously I need to do some rescheduling of this event. And that's made easy by the new availability window the iCal has. So let me just pull that up here. Just move these windows around a little bit.

Okay. So we see iCal's availability window. So this is going out in real time and fetching free busy information from the server for each of the attendees to show for us. So again we see on the left and right we see the office hours on available information coming in.

And we see the actual time frame for the event that we originally specified is highlighted here. And we can see that overlaps a busy time in Wilfredo's calendar. So what we want to do obviously is move that to a suitable time that's free for all of the participants in the event.

And iCal highlights that particular time range in green here. So I could quite simply drag this event over to the green area if I wanted to but there's also a quicker way to do that which is an auto pick option and down in the bottom right hand corner here there's a little button I can click on and iCal will automatically find the next available slot for all of the participants in the event and move the event to that particular time for you. So having gone through that process we found a suitable time slot for the invitation. So all I need to do now is click send and send the invitation off to Wilfredo. So let's have a look and see what that looks like on Wilfredo's side.

I'm going to go ahead and reply walla we've done scheduling in iCal. Now, this is actually going to send data back over to the server and which Cyrus is going to be able to notice

Click. Right. (applause) You missed that one. (applause) Okay. So I'm going do launch my copy of iCal and. And it's going to refresh that and in fact I do see Wilfredo's reply here. And if we zoom in on that you can actually see the little green checkmark next to his name which means that he's gone ahead and accepted that event. We are still waiting for Chris to reply, of course, but then he's always slow in replying to events.

So we click okay to that. So that shows you free busy look ups availability and scheduling. The other feature I want to talk about quickly and demonstrate is the delegates capability. So again I'm going to go into iCal's preferences and I'm going to look at my accounts. And here we have the server and there's a new delegation tab here.

So the top panel is actually showing accounts that I will be able to access if someone had given me the right to see their information. No one has actually done that. Because I'm obviously not that popular. So I go in look under the option to manage my own manage tell people who are going to be able to see my calendar information.

So right now I've got this set up so that my boss, Chris, who's my project manager is actually able to read and write calendar information on my server. So he can assign me tasks and manage my calendar as well if needed. Wilfredo has read only access to my calendar. Sometimes he needs to see what I'm doing what particular project I might be working on at a particular point in time. So what does this look like on Wilfredo's side? How does he actually see my calendar information? Well let's have a quick look.

So you can see that there is actually there's Cyrus's calendar right alongside my own. Obviously he gets a little busy because you see multiple people's calendars on there but you can turn that on and off. And that way I can kind of like see well if Cyrus isn't around may be he's over in some meeting over here.

So that's kind of a cool feature. One more thing we are going to show is if you've been following along with what we've been doing with the Wiki server in Mac OS X Server there's a calendar built into that. I happen to be a member of this group called Wiki users. And obviously I can create events here. That's going to cause me a need to log in. Since this Wiki requires log in to do any editing. I'm going to go ahead and do that. Create the events. I'll call it Fubar because I'm clever.

And, you know, you can move the meeting around from one place to another. If you're particularly clever, you can actually set up iCal to see that information. So sure enough there's the meeting in iCal. So we're looking at clients of different flavors. In one case Cocoa client and another place web based client and you can imagine how this will play out across platforms and so on. I am going to go ahead and get out of here and we are done with the demo.

Okay. We go back to slides, please. So that was a demo of, you know, a couple of key features in iCal that leveraging a power of iCal server and CalDAV to do enterprise calendaring. We are going to have another demo in a little in a short while like you say yet another client, a client that's not a pure calendar client actually using the CalDAV data the CalDAV protocol to access calendar data as well.

So where are we with the CalDAV specification itself? I mean right now there is something like 15 CalDAV servers that are being publicly announced and that are being worked on And we see the list of those folks here. There are about nine or ten clients that are being announced again in various states of support for the CalDAV specification.

Of particular interest and the questions we were getting at the lab session yesterday, you know, was there any support for Outlook to talk to CalDAV servers. And the Oakland connector dot org group are actually working on an Outlook plug in that will actually allow Outlook to talk to CalDAV and if, you know, any of you folks are interested in getting involved in that it's an open source project. So Please go ahead and at least let them know you are interested and maybe participate in that as well.

As clients we have other types of products that are out there. Obviously libraries to enable you to write your own CalDAV clients. There's a Java based library and a Python based library. And then we have this other class of application which is not pure calendaring clients but are consumers or users of calendaring information or free busy information, scheduling information. And we are starting to see more and more of these types of clients interested in actually accessing this calendar data directly. So iCal server and CalDAV has become more than just a calendar access protocol it's become more of a platform for accessing this type of calendaring information.

The next thing I want to talk about is CalConnect. CalConnect is the calendaring and scheduling consortium. Apple who's actually been a member of CalConnect for over 18 months now. CalConnect is a venue for users and vendors to come together to talk about calendaring issues. The primary goal is to further development of the standards and also to improve interoperability across the board.

There are usually three face to face meetings a year and each of those typically includes an interoperability event. And Apple and many of the other vendors that you saw listed there under the products participate in those interoperability events. The engineers sit down and they try to bash on each other products and see what falls over and get things fixed immediately. So it's a very good venue for actually developing products and solving interoperability problems and actually moving the specifications forward. CalConnect itself also has technical committees which are looking at specific areas within calendaring.

There's a technical committee working on free busy information looking at being able to get that free busy information through simple HTTP requests and doing this type of federated free busy work. The time zone committee is looking at how to solve the problem of governments wanting to change their daylight savings times quite frequently.

And we really want a way to deal with that so a standard time zone registry will hopefully get around a lot of the problems that we had earlier this year. Mobile calendaring is obviously a big area that people are now looking at in much more details. So again we have a committee that's looking at that.

Use cases they are looking at how resources might be described in calendaring data. So there is a need to specify for example what's the capacity of a room? So that when you do a scheduling operation, the server can be a little bit smart about that or picking a room suitable for the number of attendees you have. Public events the ability to get events from general web services, et cetera and have more detailed venue information about those and also deal with localization issues.

And then there's obviously a tech committee on CalDAV that's working on improving the protocol and handling the HR ability events. So the members in CalConnect since WWDC last year we've had quite a few new members in CalConnect or major note we've got Sun, Zimbra, Kerio, Google, Synchronica, Scalix, et cetera. So it's a thriving community, it's a very active community, and it's a good place to go if you have calendaring and scheduling products or solutions that you want to develop further. You want to do interoperability testing with other people and so on.

So let's actually move on to another demo here. And I'd like to invite Tony Becker from Marware to come up and actually give us a demonstration of his product, Project X.

Thank you, Cyrus. Okay. The mike's working. All right real quick. So Marware has a project a product called Project X. And this is basically what it looks like in network mode. And you can use it in either outline, time line in, you know, whatever suits your fancy.

We have a number of features. We have the ability to add media types if you are doing production type of things. We basically certainly do have a calendar that shows locally what's going on. We can deal with resources. We can basically take these people this is basically somebody that I've dragged in from my address book and I can show you that too. So I can just take this person and drag him in here.

I can show costs, dates, the tasks, the resource, specifications everything else that's associated with the project. Now, calendaring is very important in a project management standpoint. And one of the things that we end up doing is publishing that information out. So we can publish a dot Mac which is very nice but tends to be read only. We can publish all these events out, the same one the ICS files that Cyrus is talking about. But it tends to go into your calendar and just stay there. So I'm going to basically just get rid of that.

So I've created a project that looks like basically the preparation for the and the demo that we've just done over the last two weeks. So what you can see in this project is basically all the work that was done last week to put this all together. And then the things that occurred this week. One of the things we've got in here is you can look at resources. Oops sorry. So these were all the people that we -- basically all three of us did the dry run yesterday. The presentation that you are all here today.

And so what we do...I'm sorry...what we do is we go and publish this and that's what I was telling you about. You can basically take all of these events and because ICS is open, you can send them all to iCal, you can -- we have a local web server for the Windows people.

We basically publish up to your dot Mac account so you can save the file, you can save the project. And what we're interested in here today is basically I can take this project and I can publish it to the calendar server that's living right over here. So we'll just do that.

Okay. And let's see what we got on my end. So I'm just going to go into iCal here and I'm going to do a refresh and we see these set of blue events that appeared here these are the tasks that Tony had created in Project X that were published to the CalDAV server and I've got my set of assigned tasks here. Now, one of the important things that I can now do I can actually go in and edit one of these tasks.

So I can use for example just change -- click the edit button here and change the title on the task. Let's make that dry run again. I want to change the notes here. So I'm going to say dry run in Moscony. I'm going to click done. And I need to just go in again and oop I should be able to send that. Hang on a second. Click.

So this is true for basically any of the people that I tasked on that event. They each got their own copy of the calendar. They can each update it. They can each add attachments if they were due, you know, a document or something else that was at the end of that event. And this is all based on the fact that this is an open standards based calendar. Any client that you have can do this with simple HTTP requests and a little bit of XML commands.

- Okay. Thanks a lot, Tony.

Back to slides, please.

So that was, you know, a great example of, you know, a part of an auto pure calendaring client actually using leveraging the CalDAV standard and these open protocols to get access to the calendaring data And not just read only access but read and write access. So it's a two way process. So with that I'd like to hand back to Wilfredo to go on with the preparation.

- Thanks, Cyrus. Thanks, Tony. That was a really cool demo.

So now that we know where we are in terms of all these standards and that was obvious a lot of material because there's a lot in play here and it's all new. So we are kin of breaking ground. You can see new products rolling out and hopefully some of you guys are getting inspired here.

How do I use this stuff? Let's say I'm an administrator of a MacOS server machine and I want to set up an iCal server. Well, the -- well, let me actually start out with what the process management looks like on this. So let's say I've got a server and I've got a bunch of clients and they're going to want to come in and connect. So what am I going to build in the middle so that they can handle all of this load? Well, first up we're going to start a master process that's going to kind of own everything else.

And if you are familiar with Apache HTTP is actually launches a whole bunch of child processes. Now, Apache does it for a different reason than we do. They do it because they select on sockets and they one per connection so might have a couple hundred HTTP processes running on your Mac OS X box, if you've noticed.

Ours is actually basically going to run one process for every CPU that you've got on your machine. The reason for this is that our server is single threaded and we want to take advantage of CPU on your computer which means we are going to launch a process on each one.

In front of all of those slave processes we are going to park a load balancer and that's basically going to deal with all the connections that are coming in from these clients. So as different iCal instances or be it a Mozilla Sunbird or Project X comes along that deals with all the low distribution across all of these child processes. Now, let's say you've got multiple machines. Let's say you are a very large organization and you've got to be fairly large in order to really have to have multiple machines.

But say I've got three computers that I want to run iCal server on because if one of them crashes and the other two pick it up and so on and so forth. They basically look all the same. They are going to need some kind of shared data storage in the back end where all that calendar data is going to live.

And in our case that's going to typically be any kind of Xsan but it can be any kind of network file system or shared data storage that you can hook up across all of the machines. So anyway you can get to one basic file system across all three machines ought to work okay here.

Unless it's like Samba or something don't do that. And in front of all three of these machines we can going to park another load balancer. And that load balancer could be in essence the CalDAV server because we've already got load balancing magic built in you can kind of just run a software process up front.

If you are serious enough to have multiple machines and an Xsan and so on, you're probably going to use some kind of hardware load balancer. And of course all the clients come in the connections go through the load balancer and they get fanned out to the appropriate servers as appropriate.

This is of course like the same technology you use for any HTTP server. If you've set up HTTP in a large scale IT environment before, this is all similar. Why? Because this is an HTTP server it's that simple. So now let's say I'm a developer this says administrators but it's lying.

And I'm interested in seeing how -- what's under the hood here. Well, first of all the server's implemented in Python. Pretty much pure Python. It uses a framework called a twisted framework which we'll talk a little bit about. We get a lot of leverage out of that. It's a fully compliant CalDAV server as we've mentioned before. Which means it implements HTTP, it implements WebDAV ACLS. We implement WebDAV quota specificationS SO you can specify quota information on collections so your users don't, you know, run away and start killing your server. And of course we support SSL and TLS for transfer layers security.

Our server binds to some kind of directory service in order to obtain information about principles. As Cyrus mentioned before principals can be users, groups, locations, resources that sort of thing. And Mac OS X Server of course that means OpenDirectory. But we actually have implemented a few alternate plug ins for different kinds of directory services. One is a flat file XML file that you can specify that in. Another is you can use the Apaches users and group files.

So if you've got an Apache server and you want to kind of leverage that same configuration you can get some bang out of that. And obviously you can write your own. And of course we support authentication via the typical ways of that is being basic and digest And we also support Spenego for coverized authentication.

Again, the servers written in Python. I'm a big fan of Python. Hopefully some of you are. It requires Python version 2.4 in Leopard we're shipping with Python 2.5 which is different than we mentioned last year we said 2.4 but we've since managed to roll out a new version into the build.

The reason we like Python is because it can be very flexile and dynamic language. It's managed to let us write an awful lot of functionality with not too much code into the calendar server. And it's a big reason why we've managed to kind of get all of CalDAV implemented in time for this conference. And for our final GM come later this year.

So in addition Python unlike Java doesn't really park you on an island you can actually C libraries or on Mac OS X you can use objective C libraries by using Py OB C and that will give us actually a really good way to kind of leverage the system's libraries kind of forward if we want to kind of plug into more things that actually are native to Mac OS X through the server.

One question of course is since this is a scripting language well, how's the performance? And our experience the performance is not bottlenecked by Python and that's partly because a lot of the really CPU intensive codes such as SSL encryption and decryption and so on is actually done in C because again we all live on an island we can just use the open SSL framework that is used by everything else in Mac OS X. At least that's the open source projects.

So we believe the server will scale to moderately arduous organizations. It's if you're Yahoo and Google and you want to implement something for the whole internet you're probably doing your own thing and you are not going to buy a Mac to do it. But, you know, if you are building out something for your organization, we think you are going to be in good shape.

Again, we use Twisted framework as the core engine that drives our server. Twisted is it's really interesting it's an open source networking framework that allows you to do any synchronous activities such as response multiple requests at the same time without using threads. And that's pretty cool because if, you know, if you love threads, then you are not me. But it makes our lives a lot easier in terms of coding the thing up. And it I believe gives us fewer bugs.

But what's interesting about that is when you are going to write a method or a function that's going to return something that it needs to take a long time to do something and that's usually because you are listening on a socket and you're waiting for some data or you are trying to write some data to the disk or you're doing some other I/O centric things that usually that sort of thing but you might have some activities that do that. Rather than waiting until that's complete and then returning an answer what you do is you return a deferred object.

And a deferred object when you are the caller you get back a deferred object and it doesn't say 24 it says I'll tell you later. So what you do is write another method that says well, when you know the answer, call this thing and then we'll pick it up from there. And so it's a call back chain based method of writing your software. So it takes a little bit of time to get use to but it's actually highly functional and pretty cool.

Twisted comes for free with a whole bunch of networking stack implementations including of course HTTP which is the one we started with. And it's got a very active development community which of course for an open source project is really critical if you are going to use that and you're going to expect to continue to kind of get any updates out of it.

Now, Twisted that web too is a library within Twisted that implements HTTP. And as you can tell by the name it's actually kind of the second run at it. What's interesting about it is that every resource on the server that's slash calendars or an event in my calendar or my principle whatever they are all implemented as objects.

And so you write a class that implements a type of resource and then they get substantiated by the server and then each resource has methods on it which handle the HTTP requests that are coming in. So if you are trying to handle a get request you implement HTTP under bar get method which takes as an argument a request object and then it returns a response object when it's done or of course a deferred response object.

Web2 dot DAV is a library that I wrote while I was at Apple when I first got started on this project to implement WebDAV on top of the HTTP support that's already in Twisted. That's actually been contributed to the Twisted project under that license which is the MIT license by Apple.

It implements like XML handling and WebDAV level one. Cyrus has added support for ACLs and quotas. It supports the support method just enough to handle CalDAV things. It does not do locking which is DAV level two but it will probably need to get around to that at some point.

And Twisted CalDAV then of course is the third tier that implements all of the CalDAV logic including all of the CalDAV access specification and all of the scheduling specification. It adds some additional ACL privileges for managing permissions for doing free busy look ups and that sort of thing. As you can see we actually managed to kind of layer a nice little stack from HTTP to WebDAV to CalDAV using this technology.

Now, as in administrator as well you are going to be interested in this bit which is, how is the data stored when you store things on the servers? So Red comes along and invites somebody to a meeting, it gets parked on his calendar as a resource. What does that resource look like on my server? Well, it's going to be a file on the disk.

It's not stored in some opaque database. It's just a file as you might see if you had Apache enabled with mod DAV. The reason we did this is because we think it's a lot easier for an administrate to kind of diagnose what's going on in a server if they can just look at some flat files.

And of course these files are just iCalendar dot ICS files typically and are very simple to kind of read they are just text. Now, properties in WebDAV are kind of a way to attach metadata to a resource. And if that sounds like extended attributes on a file to you, then that's what I was thinking. So we actually ended up just mapping properties to extended attributes that's on the file system.

So if you want to actually see ACLs and how they are implemented up for a given resource or whether iCal has set a color on a calendar collection that sort of thing if you look at the extended attributes on the appropriate resources, you can actually see XML globs in there which describes what's going on in the property.

We actually do use databases for indexing and that's simply for performance reasons. If you want to look up an event by UID and a collection that contains 10,000 events, you don't want to have to open every file and check for the UID after parcing the iCalendar data. So we keep a sequel index that actually indexes UIDs and time spans for events and some typical things that are searched for very often so that we can kind of look them up, narrow down our search field and then poke at the right files without having to scan through everything.

What's interesting about this for you is that these indexes are disposable. So if you think it's corrupt or if you think it's kind of bugging you for some reason, you can just go ahead and delete the dot DB dot sequel lite file and whatever collection and it will go ahead and rebuild it next time it needs it.

Also of interest if you are just backing up all of these files all you have to do is copy the data repository to whatever you want. You just do a CP with dash R and you've got the whole backup done. You don't need some opaque tool set in order to handle that. If you're doing a backup, you don't need to backup the index files obviously because as I've said before they're disposable and they will regenerated next time around.

So principal data storage is a little bit different. So that's basically like how do I find out whether Cyrus has an accounts on the server and how does the server kind of look all that stuff up? And it does that using some kind of a directory plug in mechanism which I mentioned before.

As I've said we implement OpenDirectory and XML and Apache files and you can implement your own if you want LDAP specific thing because you are not going to go through OpenDirectory to get the LDAP you can write your own of that or if you've got a proprietary back end data management system through your users or you want to read out off of an Excel spreadsheet whatever you want, you can just write your own there. Of course our default is to use OpenDirectory.

So this is the API that you code to if you're going to actually write one of these plug ins. There's only two classes you need to worry about. At the bottom you see a directory record and that basically represents a person or a resource or a group or a location.

And it knows what service it's associated with which is going to be up on the top class and knows what type of record it is. Again if that's a user or a group or a location. It knows its GUID everything has to have a GUID on the server.

That's kind of how we uniquely identify everything. It's got a short name which has to be unique within the type of record that we're talking about. And of course the full name which will be my entire name and a bunch of calendar user addresses. That's an interesting little bit there which is this that last property is an array of URIs that you uniquely identify a user. So in my case it might mail to colon WSanchez at Apple dot com.

It might also be HTTP colon slash slash the calendar server slash principal slash user slash WSanchez. It might be URM colon GUID colon and my GUID. And those are just different URIs that the server recognizes as being me. So iCal can use any of those things to, you know, when you attempt to add in the attendees area it can translate my name to any of those values and the calendar server will know who to invite to a meeting.

And the service is a bit simpler. It needs a realm name it needs its own GUID and it needs to tell me what kind of records it stores. If you are the Apache users in groups you only have users in groups. You don't really have location. If you are a DXML file or OpenDirectory you've got some more record types that you can provide.

There's a method for listing what all the records for type are. Another one for given a short name and the type what's my record given a GUID you can look it up. And then given a calendar user address again the server can -- you need an API the server can use to actually uniquely identify that.

So in the OpenDirectory case of course it's going to get me E-mail address out of the OpenDirectory system. It's going to get a GUID out of my record in OpenDirectory. And it's going to get the URL out of the calendar servers implementation of how URLs are represented there. And at the bottom of the iDirectory record there's a method for verifying credentials which is how we handle authentication.

So if you're interested in any of this kind of development work and you think you want to contribute or you want to follow along or you want to file bugs or whatever, you want to go to WWW dot calendar server dot org. That's actually a part of Mac OS forge. The entire server is under an Apache 2.0 License. So that hopefully is amenable to most people.

Thank you. All of our bugs are in Trac. So if you want to know what we think is broke with the server, you can go right now to that website and find out what all the things we think we need to fix or what other features we're hoping to add in the short and so on. If you want to file a bug if you wish it did something or if you notice that it's broken, you go to that same website and you can file a ticket there and we'll see it.

You can of course use Radar. That is bug report dot Apple dot Com. And that will get to us through the Apple channels but then it's obviously not everybody has access to see what's going on there. So the probably the best way for you to do that is to go through the open source site. There are mailing lists for users and developers. So if you're interested in, you know, talking to other people about issues with administering the servicer, then join the user's list.

If you're interested in contributing to the development helping us with documentation which is something where we're sorely in need of right now, then you can join the developer's list. And those actually are third mailing lists for getting the subversion commit notifications. Every time we check in a fix or whatever you can actually see what's going on there. Or you can get that through our RSS from Trac.

And of course new developers are welcome. This is an open source project. We announced it a year ago. It's been open source since then so you can actually see all the history all the way back to there and actually a little bit pass that. So we're trying to keep this process as open as possible. And we'll try to make it as easy as possible for everybody to contribute.

Thanks.

So the big question is, can I actually use this? Or am I going to get fired? And the answer is, I'm pretty sure you can use it and it's going to be just fine. In fact, we're using it at Apple for the iCal team, for our team and for a couple of other teams at Apple and we're trying to grow that out a bit so we can get some real reliability testing on it and some, you know, find out exactly what the user use cases look like. But it's mission critical for us too.

So if it's broken, we are going to care just as much as you are because you know Chris likes to know where I am. So it's just as important for us. And nobody on either team has been murdered yet by anybody else at the company. So we are doing all right.

So if you need more information about the server or what's going on, Matt Drance is our technology evangelist for both iCal and the iCal server so he's a good guy to contact for that. Of course the WDWC website is a great place for additional documentation and support and so on for all of the Mac OS X technologies.

And please go visit calendar server dot org and see what's there. We've got a lot of updates that we need to do to that site. We are aware that we need to play catch up there. Again, if you are interested in pitching in there that's really cool too.

And we had a lab yesterday at the IT lab downstairs. We got another one tomorrow. So if you are interested in getting some face time with us, you want to try something out, maybe you're actually like Marware and have been tinkering around with CalDAV and you want to try something out. You can do that with us tomorrow at 9:00 a.m. And in summary calendaring services are finally here in Mac OS X. And we hope that you're going to finally be able to leverage this and make real use out of it.

The key functionality is all in place in this seed. We were actually, you know, targeting the original GM date for Mac OS X so we are kind of ready to go. There's plenty more that we can do and certainly there's a lot on our Radar but the Leopard feature sets pretty firm at this point. If you are interested in doing extensions to the server, we'd be happy to help you out. Again, you can join one of those mailing lists or you can come see us at the lab tomorrow and ask us in detail about what you are trying to do.

And as evidenced by the Marware demo on Project X, standards really create a lot of opportunities because the fact that we are using CalDAV means that there's going to be a window story, which is very important for deploying the server. There's going to be like Microsoft is unfortunately absent from the standards group that we're participating in. But interoperability among all the other vendors including Sun and IBM and so on is looking like it's going to actually jell together. And that's really very promising for a future of heterogenous computing environments.