So we're here to talk about some new technologies in Leopard Server and Leopard Client related to calendaring. And I want to first talk a little bit about what we've done with Mac OS X in the past. Mac OS X and Mac OS X Server related to collaboration technologies in the past. So, we've got a great mail client. We have a great mail server with CyberSciMap and PostFix. We've always had the Finder, which was able to support numerous file services such as AFP, SMB, and WebDAV.

With instant messaging, we support AIM. Last year with Tiger, we added Jabber support to both the client and the server. We've got Safari, which is a great web browser. Apache for serving up the web content. And starting with Leopard, we now have Teams, which serves up a bunch of interesting content. But we've always had this hole in the space of calendaring. We had a great client, but it didn't really have a server to talk to, and it didn't really have the collaborative features built into it. And Leopard is changing that. We're adding iCal Server.

So I've been introduced to you about four times now, but I'm introducing it one more time. So I want to talk about four major things. I want to talk a little bit about the features. I want to talk about the standards it's based on. And talk a little bit about the integration with Mac OS X Server, and then talk about how we can scale the server.

So starting off with features, most of you, I'm sure, use calendar servers of some sort, whether it's Exchange or Meeting Maker or any of the other servers out there. iCal Server and iCal support all of the features you would expect us to support. So we support multiple calendars, which allows you to organize your calendars into different categories.

Of course, you can invite people. It would be uninteresting if you couldn't. You can browse free/busy, find out when people are busy so you can find the proper time for scheduling a meeting or an event. And of course, you can invite rooms and resources. So if you can't invite a room, it can be very difficult, especially in Seattle, where it rains a lot.

Resources allow you to do things like invite projectors to a room. If you've got a projector that moves around from room to room. And we have full open directory integration, which means that all of the users that are in your directory system already will just automatically work with the new iCal Server.

Excellent, excellent. Well, first I'd like to thank you all for coming. I'm Mike Hay. This is Scott Adler. We'd like to show you some of the new things we've been doing in iCal. Before we show you the new stuff, let me just run through iCal for those of you who might not have seen it before or may not be comfortable with it. iCal is Apple's calendar app, ships on every Mac, ships with the OS, best known for its bright colors and its multiple calendars.

As you can see over here on the left, we have multiple calendars. We actually have groups of calendars. We'll get back to that in a second. You can see how all the different events show up in different views. That's not a very interesting week. Got different days. Let me go back to this month because that's what you care about. There we go.

So we can do banners. We can do all the stuff you'd probably expect. If I drill down to any given day, you get a nice concise view of the day. If I drill down to, let's say, any event, we actually allow a lot of information to be placed on the events.

So we can have a title, a location, as abstract as you want that to be, date and time, obviously, which calendar it's in, and driving directions, which I pasted in from an email. So we can have a title, a location, Let me go back to the month view for a second.

So iCal is very easy to use and it's had a lot of success. You can very easily change your calendar. If I decide, for instance, I want to do these chores a week in advance, I just drag and drop, and the event moves, and the time changes. It's very easy.

I can also show different calendars. I can kind of wean down to just one calendar view or the other. The interesting thing, and you might have asked yourself before, why does Apple put "I" in front of everything? Well, in our case, we can actually tell you. We are the Internet Calendar app. So you can actually publish your calendars to the Internet or subscribe to other person's calendars. Let me go to Safari for a moment and show you how that works.

So if you have a calendar that you'd like to share with other people, you can very simply put it up on a website, just have a link that other people can click on. And when they click that, it will launch that URL straight into iCal and you can very easily subscribe to it.

I get a chance to rename it if I'd like to rename it. I can strip out things that I might not want in my calendar, say "OK," and then it shows up over here in the calendar list with the rest. I can go through. And I can change the color if I want. I'm picky, so I always do that. I can get rid of these other calendars, so you can see just this calendar, and this shows us the moon phases, which is kind of an interesting thing.

So, more interesting to this crowd is obviously CalDAV. We've built the CalDAV support right into iCal. So, CalDAV looks just like everything else in iCal, works just like everything else in iCal. Calendars from the same account are grouped together so that you can organize them better, but otherwise the appearance and the behavior is pretty much the same as everything else in iCal. So, now that you're a little bit more familiar with iCal, let's take a closer look at the iCal features that have to do with CalDAV. Scott? Okay. So, let's go to my account here, and I'll go to my work account.

So, you saw Mike's account have all the CalDAV information in it, so, and you might have seen some of this in Red's demo yesterday if you were at the server overview, but we've added this accounts pane because you could have multiple CalDAV accounts on different servers, and I'm going to use my Apple account here.

And what we're going to do right now is to use the open directory server. So, all I need to do is add my username and my password. And I'm going to use my Apple account here. And what we're going to do right now is to use the open directory server.

And once I hit tab, it's going to go out to open directory, get my full server user address, and then in the background it's going to start loading everything and pulling down all my calendars. So, what it's actually done right now, this account didn't know anything about, this machine didn't know anything about the CalDAV server, it just had the open directory server in my open directory list.

So, it now went, detected all my calendars, and you can see I have a whole bunch of calendars here that I have up on the server, and I've already have events in them because I've been using this. This is my work account. So, I have my, and I have all these different things grouped.

So, one of the things that we can do here is that I can create new calendars on the server. So, we've modified this so it knows the difference between local and accounts. So, I'm going to say I want to make a new calendar up on the server. And I can create a new calendar and I can call this WAC demo calendar.

And I can create another one and I can call this. Meetings with developers. And I can add things to them. So, if I'm going to make a meeting here, I could just create something. I'm going to have a meeting with some developer who is not going to, who's going to still be here on Friday, let's say.

So, I can make a new meeting here. And I can also just, if I don't like these, I can just delete these calendars. And it's all just going up on the server. And that's what you'd expect. That's the thing about CalDev is everything in here is exactly what you'd expect. It's just stored off on the server.

So, the big thing about this is it's all running on DAV. And since iCal already had some DAV support in it, we just built on top of that. And it's all using HTTP. You might have heard something about that earlier. So, it's very well understood protocols. So, that's really cool. And I have this on my work machine. But let's say I go home.

If I go to my home machine, the important thing here is that I just can do the same account setup. At home, let's say this is Apple work. And... here, and then just my password, and does the exact same thing, goes out, detects my calendars, sees the new ones I created, including the WWC demo. It knows the colors that I've set on the calendars, all the changes.

So it's really important that you get the exact same data in both places and you don't need to use sync. You just, it's, the truth is up on the server. So that's the big thing with CalDev is that you have one place for all of your data. You could also get to this from other clients too, but we're showing how this works in iCal. So that's great, and you might be wondering why did it take two of us to demo CalDev. Well, that's because one of the great features of CalDev is the scheduling spec. So there's a draft spec for scheduling support in CalDev, and we've implemented that spec.

So I can make a, let's say I want to do a lunch meeting with somebody, I don't know who, so let's go to this and let's say I'm going to do lunch here, and I'm going Lunch, and we'll go to my favorite place, the Zuni Cafe. Don't all go there because I like it so much. Oops.

Yeah, that's fine. So I'm going to go to lunch, and let's see who I'm going to invite. And I'll invite Mike. That's great. And it'll go off to the server, and it'll ask for a free busy report. And if you see here, I can zoom in on it, there's a little slash next to Mike's name, which means he's not available.

So that's kind of a bummer, but I really want to go to lunch with Mike. So I'll just move this to tomorrow, and I'll see that he's available. And then all I have to do is send the invitation, and the server takes care of the rest. Great. So let's take a look at the invitation that you receive when somebody invites you to a meeting. Go back to my machine.

And-- What we'll notice if we show the doc is that iCal has this little notification that tells me there's something that needs my attention. There's also a little indication over here and little indication over here that shows me that there's something there. Let me take a look at those notifications.

Now I see that there's a lunch invitation from Scott, and things are a little busy, so let me turn off a couple of these calendars so I can see a little bit better what's going on. Luckily, lunch does not conflict with my drinks with the iCal team. Let me go back here, click on that.

Let's look at that in the week view. So you can see in the invitation in the inspector over here, I can choose to accept the meeting or refuse. I'll accept. I can choose which calendar I'd like this to go into. I'm actually going to put this into the iCal calendar.

You'll also notice that the event blocks out space in my calendar so I can tell where or when this event would take place. So I'll just go ahead and accept this. And you see it's added to my calendar, the notification goes away, works pretty smoothly. Okay, so if we go to back to my account here.

and you'll see I also get a notification that Mike's replied. I can click on this event and it brings it up in the inspector and it says that yes, Mike has replied and all I have to do is just say okay and it gets rid of the notification and there we go we just have to meet tomorrow for lunch.

There's a couple more subtle clues that you can use. If you want to stay in one view or another you can see there's a little check mark next to the person there that shows that all the attendees have replied and you can see there are different icons depending on the status that show up over here in the inspector.

Let's go to a more real world example. I'm sure many of you in a work environment will actually not just invite one person to lunch, you'll actually create a meeting with a lot of different people. So let's turn a couple of these back on so I know what I'm doing and let me schedule a dinner with the whole iCal team. Since we're all up in the city this will be kind of novel.

So we'll go in and Make a dinner event. I'm not really sure where we're going to eat, so I'll leave that blank for now. And since there are many people I want to invite, let me just show you our people picker. As Scott mentioned earlier, we're integrated with Open Directory, so I can just go here, and I get a list of everybody who's on our Open Directory server. And then in iCal, I can simply go through and drag people into the meeting.

and they'll get added one by one. And you'll notice as Mike's adding them, they've got a little spinning cursor next to them, which is them checking the free/busy, and then it'll go away if they're available or if they weren't available.

I'll get an invitation and I can see all the people on the team who are invited.

I can see Mike organized it and I'll just move it into, I'll say I'll accept this and I'll put it into my meals calendar and reply. So following on the theme of this is a more real world example, in the time that it took Scott to reply, I've actually called the restaurant, figured out where we're going to go.

Go back to my machine, just for kicks. Called the restaurant, figured out where we're going to go. We're going to go to Buca di Beppo. And we've got a reservation and they told me on the phone that they won't actually seat us until everyone's there. So let me just add a note here.

Maybe we need a spell checker in the notes field. And I'll send that out. And now everyone who I've invited, as you notice here, the icons have all changed. Let me zoom in a little bit. To show that I've sent an update. So everyone now has an update waiting for them to tell them that the meeting has changed slightly. So if you go back to my home calendar, you'll see I get an update to the meeting, and also over here in yellow, all the things that have been updated are highlighted for me. So I can see if there are new attendees added, we'll get that.

So what I wanted to show you, just in closing here, was I can even subscribe to my calendar from my Tiger machine. So over here, I happen to have the URLs to the server. And I can just go in with the existing version of iCal. and just like the other calendar that I subscribe to, I can rename it if I like, I can strip things out if I wanted to.

But as you see, I can access these calendars that are up on the CalDAV Server even from older clients or from other clients that simply support publication and subscribe. So we think this is going to be a really big deal. There's one more thing we wanted to mention, which is in Steve's talk yesterday morning, he mentioned that there's a to-do service. There's also a full event service that goes along with that to-do service.

If we go back to my home calendar here, one of the things that we have is that this entire API that lets you get to all of our calendar data, so the calendar store framework, lets you get to all the data that people currently have on their machines, and also it'll let you get to all the CalDev data that people are downloading when they connect to their server.

That data will be available just like everything else on your system, and there's great APIs for you guys to build applications for with these. We use it internally. We use it for mail, you saw, with all the to-do features, and also the new calendar widget. If I bring up this, it has another pane here that shows all of my upcoming events here.

So this is... and if you notice these events are things that are up on the CalDAV server. Some of them might be local too, but it's just the way the calendar widget shows it shows everything for me. So there's a session on this today at 3:30 in the Presidio, so please come to that session and thank you very much. Back to you Chris. Thanks Chris.

Great demo. Do you guys actually have two machines that work when you're... or do you guys have to work like that? So I want to talk about standards a little bit. One of the things we try to be very, very careful about with Mac OS X Server is that we don't use proprietary technologies. We like to use open standards. And if you look at some of the services in 10 Server, it's very clear that we've been doing a very good job of that. So of course, we adopted a standard for calendaring.

There have been attempts to create standards in the past. Probably the most famous one is Calendar Access Protocol. And it's sort of the older, ill-behaved brother of CalDAV, I guess. It just never really grew up. Didn't really get along well with other people. Just kind of stunted. Problem with it is that it tried to do everything from scratch. It created this very, very complex protocol.

Maybe one or two people adopted it. I'm not sure if anybody ever adopted it. And this lasted for like six or seven years. So it was not good. So we looked at that and decided that really wasn't where we wanted to go. CalDAV, on the other hand, is built on top of a bunch of protocols that already exist.

And that's a good thing. So here are some of the protocols it's built on top of. You'll notice that all of these things have RFCs attached to them. iCalendar, that's the file format that describes events. iTip is an extension to iCalendar that adds the ability to do things like invite people, just to the data format. HTTP, probably the most popular protocol in the world right now. WebDAV, which was designed for allowing collaborative document editing in HTTP, has also been used for other things, such as file servers, like at .mac.

And what it basically does is it adds kind of a data model to WebDAV. It adds collections, which are the equivalent of directories in a file system. Gives you a couple of new methods. You can copy files between directories, move files between directories. And really importantly, it adds metadata to those files. So you can attach metadata, which is actually really important when it comes to trying to do calendaring.

And a couple of other lesser known standards are the WebDAV access control protocol. So that's what we use for providing access controls on all of the events in the calendar. And there's another WebDAV standard called Delta V which is their version control. We just stole one of their methods, which didn't steal.

CalDAV takes one of their methods, which is a report method for allowing you to do queries against calendar. So anyway, we took all of these standards, which are all very solid standards, well tested, well used, put them all together, added a little bit more to them, and came up with CalDAV. CalDAV adds just really a little bit more. It adds make calendar method. So that's a method that tells the server, please create me a calendar collection.

Adds a schedule method, which is just a method that says, I'd like to create a meeting and send it off to people. And with the addition of this and then some semantics for where these things go and how they get passed around inside the WebDAV repository, you end up with CalDAV, which is built on top of a very, very solid foundation of existing standards.

Here's a protocol stack. So HTTP at the bottom. Then you've got webDAV on top of that. iCal under the file format that we're using. iTip provides a little bit of the scheduling sauce we need. And then CalDAV on top of that. And then off to the side is LDAP because iCal Server is completely integrated with Open Directory or LDAP.

So how does it work? It's not that complicated. It's maybe a little more complicated than five bullets. But basically, when a user wants to invite somebody to a meeting, they have an inbox and an outbox. And these are basically just directories in WebDAV. So if I want to invite somebody to a meeting, my client will drop a request into my outbox.

The server will pull that out of the outbox, look through the list of attendees, and then make a copy of that event, and fan it out to each of the attendees' inboxes. At that point, the client on the attendees machine notices there's something new in their inbox. They pick it up, show the event to the end user. The end user says, yes, I'll attend.

No, I don't want to attend. I'll decide later. And when they're done with that, their client puts that event into their outbox. Server notices something new in that outbox, picks it up, sees that it's a reply to the originator, puts a copy of that event into the inbox of the originator.

The originator's client sees that, picks it up, updates the original event with the attendees' status. It's all very simple, isn't it? And then additionally, users can be set up to auto-reply. So some people like to have their calendars auto-reply if they've got time available. Rooms and resources have to be done this way. So basically, a room will always reply yes if it's available, if it's not being managed by somebody else. Somebody else? I want to show you a little bit about, or a little bit of the file layout.

So, Like I said, this is all web-dev based, so these really are just file directories and files on the file system. So, with iCal Server we start off with a calendar collection that contains three collections. One that contains users calendars, one that contains group calendars, and one that contains resources. So, kind of diving into the user calendar, you'll see three users here: Cyrus, Chris, and Wilfredo.

And in my calendar collection, I have two calendars. I've got a work calendar and a home calendar. Now those calendars are actually just another directory. There's nothing really that special about them. But inside of them are very special things, and those are the events. And I've got two events in my calendar.

And these events are just iCalendar files or ICS files, the same files that iCal's been using since the beginning. And kind of a key point to all of this is you notice an HTTP URL at the top, right above event number one. Because we're using web dev, which is based on HTTP, every single event is addressable by a URL. So even if you're not building a full calendar client, you can still do some pretty interesting things just knowing that you can get to anything with a unique URL.

Groups are the same structure. A group will have a calendar. Groups also have members. So in this case, the software group calendar is accessible by me and Cyrus. We can both read and write that calendar. This is useful for when you're dealing with projects. And resources, this is where we put the calendars for things like rooms and projectors and other things that don't talk in meetings.

So why did we choose Kite CalDAV? There are a few reasons. We actually started looking at building a calendar server a little while back and put a bunch of effort into designing a calendaring protocol that we wanted to be open. We were going to, as Apple, try to create a protocol and push it out to the world as a standard. It actually got fairly far along with that, and very strange, it was based on WebDAV, included inboxes and outboxes, used the iCalendar format, and then we were probably about a third of the way through this thing, and then this thing CalDAV popped up.

It looked just like what we were working on, so the timing was absolutely perfect. We decided rather than go it alone, we would jump on board with people designing CalDAV. Second thing is, as I mentioned, we like to keep things as standard in Mac OS X server. CalDAV's totally open. It's run being run through the IETF as an open source. Open standard. Third thing is that it's being adopted.

The worst thing to do is to create a new standard and nobody comes to the party. Not something we wanted to have happen. We don't want our product to work just iCal server and iCal working together. We want our product to be able to work with all the different clients out there, numerous servers out there, so it's important that it's being adopted.

We also noticed it was being adopted. There are people already adopting this. So Oracle's announced that they're adopting CalDAV. Novell with their Hula project has announced that they're going to be adopting CalDAV. So it seemed like everybody who would in their right mind adopt an open standard did, so we decided that would be a good thing to do.

Then also the future is being designed into this protocol. This is not a protocol that's like very tightly coupled. It's actually very loosely coupled, and you can see that based upon all of the different protocols that are involved. One example of this is a group of the people involved in CalDAV a month or two ago did an experiment where they allowed free busy information to be seen between different servers from different companies.

And so what this allows in this experiment is for somebody from Microsoft, for example, to invite me to a meeting, and while they're inviting me, see my free busy. That's a pretty important thing, especially in the university world where you guys are definitely a lot more open about letting people see free busy information. And the experiment went well.

It wasn't all that difficult to get the thing working, and there's actually a technical committee who's working on completing this and making it part of the standard. And the last thing is that CalDAV is being designed by some people who are extremely well organized. A lot of standards are kind of grassroots. Efforts by people who are trying to go through the IETF. They're not very organized. They get disorganized. Things fall apart. One guy becomes a bad guy. The good guys all quit. And that sort of thing. CalDAV doesn't really have that problem.

It's being designed primarily by a group of people who are members of an organization called CalConnect. And CalConnect is doing a great job of getting the standard defined and then pushing it over to the IETF. So they're fast tracking that way. And they avoid a lot of the problems you have with IETF. And to speak about CalConnect, I'd like to invite Dave Thewlis, who is the executive director of CalConnect.

Thank you. Yesterday I couldn't figure out how to use this, so I was technology challenged from the start. As Chris said, I'm the Executive Director of CalConnect, which is the calendaring and scheduling consortium. And I'll talk just a little bit about what it is and what we're about, and then I'm going to go into a little bit more detail about the things that we're actually doing.

CalConnect is an information technology consortium. It is actually a 501c3 nonprofit. We tend to think of it, or I tend to think of it, as a partnership between developers and customers. We have a variety of different types of members, as you'll see, but it's a very collegial organization.

And people who are actually developers from vendors or other organizations that are developing calendar applications, and people from customers and users that are actually users of these things, are working together to help evolve the specifications and help do interoperability testing and such things. Our mission, although it has a lot of fancy words in it, boils down to the fact that we are dedicated to driving interoperability between different calendaring and scheduling systems. To that end, we develop requirements.

We develop requirements and use cases for standards. We help to evolve changes to standards to support calendaring. We also provide a place where work on the specifications can happen between individuals and organizations, and then the specification can be furthered into the IETF or conceivably another standards body, if that's the appropriate thing to do with it. We definitely conduct interoperability testing either between existing systems or interoperability testing against the RFCs to ensure that the specifications are done correctly. And that the specifications are properly implemented.

And in a sense, what we're trying to do is to push the industry towards interoperability. Calendaring up to now, especially in organizations, has largely been a case of individual islands. Some proprietary server and the clients associated with that. So you can do calendaring within your organization, but you can't do it between your organization and another. Frequently, even if it's the same system, and very definitely if it's different ones. And our goal is to make sure that, calendaring systems can interoperate and that calendaring for individual people can interoperate.

As far as who's involved in CalConnect, calendaring vendors such as, Chris mentioned Oracle and Novell, both of whom are members. Academia, many major universities that are heavily involved in calendaring are now members of the organization. Commercial companies, we're starting to get membership from organizations such as Boeing. Open source developers, governmental entities, NGOs, individuals.

This is an incomplete slide, but it does show many of the members and as was announced yesterday, and I was here to welcome Apple to CalConnect. Now the reality is that Apple has been a member of CalConnect since January, has been heavily involved in work on the CalDAO standard and other evolving work that's going on within CalConnect.

Chris alluded to the Free/Busy proof of concept demo. This was conducted by CalConnect. And it was actually about three weeks ago. What we demonstrated was collection of Free/Busy data from seven different calendaring systems, which included, as it happened, Microsoft Exchange, Lotus Notes, and several CalConnect-- sorry, CalDAV implementations. The core of this was a Free/Busy aggregator based on CalDAV. It was a CalDAV implementation from beadwork, which is Rensselaer Polytech's open source implementation of CalDAV.

And then CalDAV proxies with connectors to non-CalDAV proprietary servers, such as the Domino's server and the Exchange server. In fact, Boeing provided the connector for the Exchange server. And IBM provided the connector for the Notes server. So we were able to draw Free/Busy data from these seven different servers, one of which was Google Calendar, and display it all in a summary through a web interface.

And being able to go on that then to start scheduling data. And this was in response to a challenge, actually, from another standards organization called the Open Group. One of their members, Boeing, was desperate for some way to do Free/Busy analysis across people in about 2,000 member organizations, member partner companies. They're spread all over the world.

And they figured that they lose an enormous amount of time just trying to figure out when everybody's available for a meeting or a conference call. So they didn't even care whether they could do automated scheduling if they could just do the Free/Busy lookup. And all of that work is in open source. That will all be made available by Rensselaer Polytech for anyone to pick up and work on if they want.

I mentioned our technical committees. Right now we have eight active technical committees. They're working on authentication and related to that the discovery issues of being able to figure out what somebody's calendar ID is if they're not on your own server. CalDAV, which is, and Chris alluded to this also, CalDAV is directly working on providing use cases and requirements for the specifications that are then being developed by the primary developers of the specs that will then go as the CalDAV submissions into the IETF and all three of the primary authors are active in CalConnect and active in the CalDAV technical committee plus some other people.

The event publication technical committee is working on extensions to iCalendar to support real event publication. We're talking about things like concerts where there's a lot of additional information you would like to carry along with an event and that kind of information varies depending upon the kind of event it is. What you'd want to provide for a baseball game would differ from a rock concert would differ from a speech being given at a university. So, and native iCalendar doesn't provide enough flexibility and enough granularity to describe these kinds of things.

So they're working on what will be submitted very shortly now to the IETF as a specification for an extension to iCalendar. TC Freebusy is the technical committee that put together the demo that we talked about and is going to be working on expanding that demo to include a new one.

We're expanding that demo to include all of the vendors that are members of CalConnect and some others will be redoing that demo at our next roundtable which I'll mention shortly. The IOP test committee of course simply develops the interop testing events and standard scripts and things like that which we make available on our website.

We have a technical committee in the mobile area which is working on being able to do calendaring into mobile devices and we're not talking about synchronization, well we're talking about synchronization here of course. One of the problems with the sync being that it's not content sensitive so you can happily sync something that your phone can't deal with. But real calendaring onto mobile devices in the future. Real time which is working on things like the protocols that are actually required to do things like synchronous Freebusy determination.

And the use case technical committee which is primarily involved in developing the use cases that will be part of building the specification system. So in fact the specifications when done actually can be used to implement things that meet the requirements that people actually needed in their calendaring systems when they have them. And then I mentioned two TCs that have just finished. One which worked on proposed changes to time zone, the time zone specifications and one proposed changes to recurrence as they currently exist in iCalendar to simplify these things somewhat and make them more implementable.

I mentioned I was going to make a proposal for people to get involved with us and we have a small organization. It's relatively new. It's about 18 months old. We are growing and we need help. We need more people that are actively involved in doing things such as helping to define the requirements, making sure that we have the voices from different kinds of organizations, from different developers, from different types of users. And the points that I make here, the reason to get involved in CalConnect is simply that you can help shape the evolution of calendaring and both the specifications and eventually the products, identifying real world requirements and use cases.

If your organization has needs that you're not sure anybody is really meeting, and most large organizations are uncomfortably certain that there aren't any products that really do what they actually wanted to do, this is an opportunity to help work directly with the developers, if you're a developer, it's an opportunity to work directly with the developers. And of course, help drive the rest of the calendar community towards interoperability. If you're interested, visit our website, which is calconnect.org.

I mentioned that we have three member meetings a year. Non-members may attend as observers to see what's going on and see if they're interested. As a matter of fact, our next roundtable is at the end of September being hosted by Apple Computer in Cupertino, or you can email or call me for more information. And of course, with everyone else, I'll be around after the meeting if anyone wants to talk more. And thank you very much.

Thank you Dave, and I'd like to second his plea for you to join. If you're a developer, you want to join because you want to help to define the standard. You also want to make sure that your stuff works with everybody else's stuff. If you're in higher ed, you want to be there so that you can let the other people defining the spec know what it is you need. Because you can actually help define the spec so that it meets the needs of your university.

So, talked a lot about interoperability, and I'd like to prove that there's some interoperability, and I'm going to invite Grant Baillie and Jeffrey Harris from the Open Source Applications Foundation to come up and give you a demo of, to speak a little bit about OSAF, and to also do a demo of Chandler working with the Apple iCal Server. Thanks, Chris.

So yeah, this is going to be a little bit of a two-man show. I'm just going to go through a couple of slides and then Jeffrey is going to come up and do the real demo part of the sub-presentation here. So, not surprising given who I work for, the stuff we're showing is an open source application and its name is Chandler.

I was kind of looking through these slides and they're in kind of a funny order, so I'm going to make a big boo-boo and do a random walk around the bullet points, so don't try to follow too closely at home. So basically what Chandler is, is it's a personal information manager. This is the third bullet point, by the way. And what it really is, is it's a hub for all your personal information, calendars, tasks, emails, and notes.

And then there's that nice phrase, orchestration of shared PIM info. There the word orchestration points to the fact that we have this great communications infrastructure and these powerful computers that can accumulate all this information. But what that really leads to is people being really swamped by their information.

And so, you know, people end up with inboxes with huge numbers of emails in them. Emails don't get replied to, people miss their meetings, people miss deadlines, stuff like that. So we're really hoping to kind of help address that problem. And the other word in that phrase that's good is shared. So, and that really points to the stuff we get by participating in CalConnect.

That we really would want to enable people to use the software. And that's really what we're trying to do. We're trying to enable a whole bunch of different kinds of shared calendars from just classic group where scenarios on a single server to, say, a group of roommates or friends or people working across companies.

So I'm going to leap back up to my first bullet point, which is the stuff we're going to show is currently in what's considered an alpha state, which means that we're really using it internally. And amongst other things, we're running our shared office calendar on it. And since it's open source, you can download it at any point.

But really, we're expecting it to be beta early in 2007, which means that it would sort of be generally usable for the general public. And then, of course, the important thing is that we're cross platform. So we run on both Mac architectures. We run on Windows. And we run on a couple of different Linuxes. So actually moving along in order to the second bullet point.

We are open source. We're mostly written in Python. We didn't go write the whole thing from scratch ourselves. We leverage a whole bunch of third party open source Python libraries. For instance, to do the cross platform GUI, there's a library called WX Python. And also some of our subprojects are available for use outside of Chandler. And there are two examples here which really are kind of the core of our CalDiv implementation. Our Zanshin, which is a high level CalDiv library.

And then VObject, which is used to read and write iCalendar format. And so it turned out when Apple went to go do their own open source calendaring server in Python, they needed an iCalendar library. And that's the one they ended up using. In general, Apple's implementation also lies on top of a third party. And so we're hoping that they'll be able to use that as well. And then we're hoping that they'll be able to use that as well. And since we actually use that as well, we're hoping that there'll be future opportunities to use one another's code.

Now I'm gonna leap down to the last point which is that we also have a CalDAV server. Its name is Cosmo. It's kind of a more traditional, Java-based server. It supports the base CalDAV spec. It also supports like being able to subscribe from Tiger iCal. And it also has a web front end which is all that nice AJAX-y goodness that people seem to like nowadays. And actually I'm mentioning that not just as sort of a shameless plug for our server, but actually to talk a little bit about open standards and interoperability.

In general, more people having more servers is good in the end for the end user, for the customer. It gives them more choice. The servers in the end all, servers and clients end up having different focuses. And so in general, you can find something that's more tuned to what you need. To get sort of a little biblical, there's the phrase that faith without deeds is dead. In the standards world, it turns out that, first of all, standards without implementation are dead.

And even more importantly, from the customer choice point of view, is that implementations without interoperability are dead. So we're very, very happy to be part of CalConnect. We're very happy in particular to attend their interoperability testing events, where basically you can sit down with all the other vendors and hash out bugs and code you've recently introduced, figure out where your interpretations of the standards differ, and that kind of thing.

In fact, the next interoperability event is being hosted by our good friends from Apple in about a month's time. And it would be really good to go there and to see the server that we've kind of guessed must exist for quite a while. And also to have stuff like iCalendar testing against our CalDev server too. So that should be really great.

So, for our contact information, we're at osafoundation.org. If you want to find out more about Chandler, the client, you can go to chandler.osafoundation.org. The server Cosmo is at cosmo.osafoundation.org. We have various mailing lists, various public mailing lists. The one for sort of high-level product design or for stuff like, oh, I downloaded it and I can't get it to launch, that would be design at osafoundation.org. And then there are two developer lists for the client and server listed there. Again, they're for more sort of technical questions. So that's the end of what I have to say. And here's Jeffrey. Thanks, Grant.

Boy, there are a lot of you. Hi, I'm Jeffrey Harris. I'm a developer at OSEF. So this is Chandler. Now, you'll notice this is running on Windows, GASP. I would have loved to use OS X instead of Windows, but they really wanted us to show it on Windows. It's much prettier on OS X.

So this is Chandler. As Grant mentioned, it's a PIM. Right now what you're looking at is our dashboard view. And what we're really focusing on are the workflows for triaging lots of different PIM concepts. So if you look here, this is a task. And then I also have events.

These little details are icons here. You can select different things, and you can make things be events or tasks, and they're all heterogeneous in individual collections. And you can triage things, so you can see here that I have three now events that are green and three later events that are yellow and a done event. The idea is that you really want to focus on the things that you want in your attention right now.

Part of what we've done is allow you to have lots of different collections. So this is my work collection of things to focus on, like give this demo. I also have a home collection. And you can overlay them just as you can in iCalm. And here's everything all together. Now, this is all fairly textual. If we wanted to, we could go over to the little mini calendar here, and we could say focus on the apps team meeting.

And we could switch views over to a calendar view. You could probably guess that we were going to have some calendar instances at the CalDev talk. So here's our... Here's our view of the home collection and the work collection overlaid, and I'm going to overlay my choir collection too.

So, one of the things that we can do is let's say I realize that this afternoon one of my friends is going to be at Stump the Experts tonight, so I'll make a new event for that and call that...

Let's see, to access it, I don't have open directory things, so I have to actually know username and password to access it. and there we go. It's downloading all of the relevant things and if we go and look at fun, here it is. Let's go.

and I'm gonna invite Chris or someone up to come and demonstrate that in fact that changed the fund collection up on the CalDAV Server.

We've actually got this up. We didn't show it in the right perspective necessarily, so let me turn off my other calendars and show that... Which week was this in? Looks like it was July 30th. July 30th.

Oh, that helped too.

So I want to talk about iCal Server and its integration with the rest of Mac OS X Server. So, as I've mentioned probably twice, maybe three times already, we have full integration with Directory Services, which means we support Open Directory.

If you've got an Apple Directory deployment, Directory Services will do the mapping for you, same for LDAP. You probably can't read the fine print there, but that's okay. No, actually all it says is that there is one additional attribute you need to add to your directory schema, which is basically the address of the calendar for each user. We also support Kerberos. So the client and the server both support Kerberos.

And like all services on Mac OS X, we provide a graphical interface for administering that, so Server Admin has support for Calendar. It's very, very simple to set up right now. We'll probably add a few more features before we ship the final version. For now, that's all we have. And the new Server Preferences application supports it as well.

And there's a new application called Teams Directory, and Teams Directory does a few different things. One is it's basically an address book for your directory, so it allows you to browse all of the users in your directory. It also allows you to browse things like rooms and resources, such as projectors. And in addition to that, it also allows you to do things like create rooms and create projectors and add maps to those things so you know where they're located. And this all integrates directly with iCal Server and iCal.

And then on the IT front, we tried to make our data store as IT friendly as possible. How many IT people like dealing with problems when they can't see what the problem is? One guy back there. All right. So the data, as you saw in the previous slides, the data format we're using is actually just iCalendar files on the disk. And those are textual files.

If there are problems, you can go in there and take a look at them and see what the problem is. Files by themselves are not very fast. So we do have a database that backs that for indexing. And that's where we get our speed. But that database can be thrown in the trash, and it'll get rebuilt automatically.

We basically use it for performance only. This creates a very resilient system. It also allows you to do things like per account backup and restore. A lot of calendaring systems require-- not that there are a lot of calendaring systems out there, but most calendaring systems require that you bring down the entire calendar server in order to fix one problem on one account. iCal Server doesn't require that.

And because the files are all living there on disk in a format that is easy to read, these are all parsable. You can write your own tools to manage the files, to provide status on the files, to provide statistics on your server. In general, the whole thing is basically very easy to troubleshoot.

In addition to that, the data that's going over the wire is HTTP and WebDAV, which gives you the XML and iCalendar. So it's all very easy to troubleshoot over the wire. Of course, this is all protected with SSL, but you can disable SSL when you're trying to troubleshoot to look for problems.

Let's talk a little bit about scalability. So we designed this thing to be extremely flexible so that you could scale it the way you want it to scale. So it can certainly start off small and grow your organization. We support a variety of different configurations in terms of scaling. Different organizations have different ways of scaling, and we understand that. And because of that, it makes it very cost efficient for you to build out your system when that time comes, when your organization gets big enough to do that.

So, if you're a small business, you can run everything on one server. Your directory server, your calendar server, your web server, your mail server can all be run on one server. Get a little bigger, move the mail server off to another server, move your directory server off to another server.

When you start getting bigger, maybe add some load balancing hardware in front of the machine, add more calendar servers, and when you get as big as we'd like you all to get, purchase an XAN. And hook that up to the calendar servers. iCal Server can support shared storage on the back end, it can support partitioned storage between servers, so it's extremely flexible.

Then the last thing I want to talk about is Darwin Calendar Server. So, we built, obviously, we're obviously including a server with Mac OS X Server, but we're taking that same source code and it is identical, exactly the same source code, in fact it's the same open source, or the same subversion repository that our engineers use, and we're open sourcing that.

apache license version 2 so that's a mistake it's not apsl it's actually an apache license which is a much more lenient license and as grant mentioned the server's written in python and it lives on top of twist the twisted framework and it lives as a twisted caldav module it's a new module that's being added that lives on top of twisted and it's available today at this um url and my understanding is that we need a more powerful server because the server is getting a little overloaded right now but feel free to download it anyway So we're providing a server that is open sourced, uses open standards, and those two together mean developer opportunities basically, and I know there are a lot of developers here. So I want to encourage you guys to look at the technologies, look at the server, and create some new products around calendaring and events. So build clients for mobile devices. Build some bridges to legacy calendaring systems. I won't name the legacy calendaring systems.

There are too many to name. Anyway. But the protocol total, you know, this standard completely allows that, and we've actually done a little bit of experimental work in that area. No, we're not doing an Exchange Connector, so don't read that wrong. But there is actually an open source project called Open Connector that is starting to do a CalDAV bridge to Exchange, which is pretty interesting. If you want to jump on that project and help them out, that'd be great.

You can build rich collaborative websites. You don't have to deal with events and calendaring because iCal Server or Darwin Calendaring Server already do that for you. You can focus on the interesting things in your application or your interesting web app. And then for the love of God, somebody please create a multi-user project management piece of software. I'm begging you. And the first person to do it in a way that I like, I will personally buy you an iPod Shuffle.

And as you guys look at the technologies, I'm sure you're going to dream up all sorts of things you can do with events and calendaring, knowing that a lot of the work is already done for you under the hood. So, let's help the world get it together. Right? We see the opportunity for all sorts of interoperability.

And as Dave mentioned, we're kind of like, we're kind of at this point where mail was when you still had to use percent signs and dots and didn't have at signs in your email addresses. This is where we are with calendaring now. And I think in five years, it's going to be just, it's going to be expected that anything that does calendaring works with CalDAV and iCalendar.