Publishing using WebDAV definitely works, but as Jon points out, it’s hard to find a free web host that will give you a calendar view of your events. It also tends to be slow for large, frequently updated calendars, because the whole calendar has to be sent every time something changes.

Happily, for Mac OS X Leopard users, there’s a better option. Leopard shipped with iCal3, which includes CalDAV support. CalDAV is a protocol that allows fast (well, faster than WebDAV) multi-user access to calendars.

Chandler Hub was designed to make Chandler Desktop sharing easy, but it’s also a CalDAV server. So if you’d like to publish public calendars and edit private calendars with friends and colleagues, Chandler Hub may be a good choice for you.

Chandler Hub is a free service that, among other things, gives you shareable web-based calendars, editable using the web or a CalDAV client.

So, here’s how to share a public calendar using CalDAV and iCal3.

Sign up for a Chandler Hub account.

1. When you sign up you’ll need to provide an email address

   

2. Activate the account by clicking on the emailed link. Once the account is activated, log in. Initially, your account won’t have any calendars

   

3. You’ll need to create at least one calendar (which Chandler calls a collection) in the Hub, or iCal won’t let you work with the account

   

Configure Apple iCal to sync with Chandler Hub

1. In iCal Preferences, create a new CalDAV account by selecting the Accounts tab and clicking the plus at the bottom left

   

2. You’ll need to expand the Server Options pane so you can enter your Account URL. The URL will be https://hub.chandlerproject.org/dav/users/your_username

   

3. Once you click Add, you may need to refresh by going to the Calendar > Refresh menu. Within a few seconds, you should see your calendars

   

4. [Optional] Now you can add new calendars directly from iCal, but it’s a little tricky. If you’ve already created all the calendars you need, you can skip this step.

   iCal won’t let you drag and drop an old calendar onto your CalDAV account, you can only create a new calendar. To create one, first select one of your CalDAV calendars, then click the plus at the bottom left.

   Unfortunately, when you create the calendar, you’ll get an iCal error message. The error message is mysterious, but happily it doesn’t prevent the new calendar from working. Just click OK and name your calendar.

   

   (Note) Don’t try to delete a Hub calendar from within iCal, delete calendars from the Hub’s web interface. If you accidentally do try deleting from iCal, it’ll make the Hub account unusable. To recover from that, you’d need to delete the account in iCal’s preferences and recreate it. No data should be lost, but it’s a hassle.

5. You should now have a few calendars to work with in iCal.

   

View and share your calendars on Chandler Hub

1. To share a calendar with the world, go back to Chandler Hub and confirm that all your calendars appear in both iCal and the Hub.

   

2. Click the white “i” in a colored box, to the right of the calendar name. You’ll see the calendar info screen.

   

3. To share the calendar with the wider public, click the Invite button

   

4. You can just send these URLs as is, but there’s one last detail.

   Chandler has two main views, a week view and a list view. The default view is list, but that’s probably not what you want if you’re sharing a calendar.

   To change views, look at the small icons near the top left of the screen. The calendar icon is on the right.

   

   If you’d like people viewing your calendar to always see the week view, you can add

   &view=cal

   to the end of your sharing URL.

That’s it! Here’s a link to the example calendar I used to make this blog post, feel free to play with it if you’d like to see how it looks without creating an account.

The first changes I’m excited about are, like our latest release, less wholesale modifications than improvements and commitments to stable APIs with performance enhancement sugar to sweeten the deal. Dojo’s internationalization (i18n) and event APIs have matured to the point where developers can expect to rely on them without fearing a future change like the one we’ve just experienced. As a result we’ve begun the process of migrating our custom i18n code to Dojo’s API, away from the custom, backend dependent code we’ve used in the past. We’ve also started streamlining our use of Dojo’s topic APIs to make our code easier to read and understand. Both these processes are works in progress, so keep an eye on this space for more detailed information in the future.

Several components have also seen essentially complete overhauls, most prominently the XMLHttpRequest wrappers and Dijit, the full featured HTML/CSS UI toolkit built on Dojo Core. Instead of using dojo.io.bind and passing callback functions, method, and header information dojo.xhrGet, dojo.xhrPost and a handful of other methods accept a variety of arguments, make HTTP requests and return dojo.Deferred objects. This return value, a port of the asynchronous task management API introduced by Python’s Twisted networking library, provides an easy way for developers to manage complex sets of asynchronous actions like server requests. Since our Web UI data APIs already used dojo.Deferred internally, this change led to a very nice code reduction.

Dojo’s user interface building API, Dijit, has been greatly improved since Dojo 0.4. In addition to moving to its own namespace as part of Dojo’s overall API flattening, Dijit is better streamlined, better tested, and easier to use. A number of Chandler Server UI components have been ported to the Dijit APIs, and are, as a result, better tested, more modular, and closer to being embeddable outside of our Web UI.

The Dojo team has also been hard at work putting together the next generation of Javascript tools to support high performance rich applications on top of the Open Web. Two of these tools are already finding their way into heavy use within our code base, and are poised to become critical pieces of our infrastructure over the next year.

The first, dojo.data, is “uniform data access layer” that allows UI components to be built without worrying about backend data formats. Our user administration interface has been essentially completely rewritten, but required almost no new UI code. All we had to do was implement a dojo.data store on top of the Cosmo Management Protocol (CMP) and hook it up to Dojo’s Grid widget to get full in-place user field editing, “infinite scrolling” for handling large numbers of users and a handful of other goodies. While our end-user calendar and item list UIs have not been moved to this API, the ongoing web widget project is being built on a new dojo.data store that we hope to eventually integrate into our current UI.

The second piece of new functionality that I’m excited about is dojo.query. This do-it-all CSS query function is the go-to guy for finding pieces of DOM to manipulate. The beauty of this and other query functions is that they are based on features most web developers eventually expect to be supported natively by all major web browsers. By allowing developers to start using these features now we can build advanced web applications that will get trivially more performant with time, and motivate browser developers to continue implementing this critical functionality.

In addition to improving the tools we use to build our Web UI, Dojo’s 1.0 line has introduced some major infrastructure improvements in the form of a DOH, a new Dojo-independent testing harness, and a from-scratch rewrite of the Dojo build system. We’ve managed to port all of our tests to DOH by writing some wrappers to avoid a completely rewrite, which has allowed us to take advantage of the very nice test harness bundled with Dojo. Nearly as important as this test framework is the build system that plays a key role in transforming over 1MB of Javascript into a much more digestible 138K loaded in several different stages. The Dojo 1.0 line makes this process much cleaner and easy to understand, as well as offering advanced functionality like layering, which allows us to break our Javascript into large chunks appropriate to different pieces of our UI.

Dojo has been an integral part of our project to build a new kind of information and knowledge management ecosystem and we are lucky to be able to rely on a vibrant community of developers producing a first class piece of software. If you’re interested in digging deeper and helping us integrate even more of the exciting new functionality provided in its latest release, Dojo 1.1, please don’t hesitate to ask questions on our development list, or via IRC on irc.freenode.net in the #cosmo channel.

Chandler Desktop 0.7.5 is available for download for Windows, Mac, and Linux at:

http://chandlerproject.org/download

Chandler is about trying to match the way people really work. And everyone uses lots of tools to get their job done. One of the first things people want to know when considering trying out Chandler software is “Will it work with what I already use? Can I switch back if I don’t like it? Will it work with the tools that friends of mine use?”

We believe the answer to all these questions is “YES”! You can safely and productively start using one or more of the Chandler Project components on top of your existing toolset. Go ahead, try it out! Read more below to learn the details.

For a bullet-list summary of our best-available notes on specific applications and which features are supported with each, see our interop overview.

Import/export

The gold standard of calendar transfer is the “ICS” file (in iCalendar format). Most calendar and task list applications support both import and export of ICS files.

You can try out Chandler Desktop without switching from your current setup. Just export one or more ICS files from your current application, then import those files into Chandler Desktop (continuing to use your current app). To switch over permanently, just export+import again a final time!

If you later decide you’d like to change again, you can export ICS files from Chandler Desktop or Chandler Hub, using those files for import into a wide variety of applications.

We’ve seen import and export work for Outlook 2003/2007, Mozilla Lightning/Sunbird, Apple iCal, and others; it should work with a great many apps, probably yours included.

Note that Outlook doesn’t export full information by default; we’ve found this $10 application from littlemachines produces high-quality exports from Outlook that work well with Chandler Desktop.

In practice, doing ICS import/export can have gotachas. Not all application combinations/roundtrips are 100% perfect. We urge you to keep backups and try out import/export before committing your important data to any application. In Chandler Desktop, we’ve spent a lot of time tuning our import/export routines to handle as many variants and details as we can. Chandler Desktop properly handles events, tasks, timezones, recurrence, and other details. Please report any import/export problems you encounter.

We’ve put together some additional information about import/export with Chandler Desktop specifically, so check that for additional hints and notes.

Synchronization

ICS import/export is great for transferring your data between apps, but it’s a manual process not suited to keeping multiple applications in sync. Usually when you import a data set, your app will overwrite changes you may have in your local copies of those events. It’s hard to make changes in two separate apps.

Chandler Desktop and Chandler Hub both support multiple network sync protocols. Where other applications (Outlook, iCal, etc) overlap at least one of these protocols, interoperability is possible on at least some level.

One main idea to keep in mind when thinking about these various systems is whether a scheme is “read-only” or “read-write” (ie, bidirectional). It seems like read-only (or 1-way) interoperability works more reliably today, but protocols like CalDAV promise a new era of real-time, 2-way synchronization of calendar data between lots of free and for-pay applications and web services.

The big news is that you can do 2-way/read-write calendar and task synchronization today, both privately and shared with other people. Here’s a list of the main ways to do that, based on Chandler Project software.

Webcal, 1-way sync

The most simple network protocol is to take an ICS file (see above in import/export) and post it to the web, so various apps can download it (redownloading to check for changes periodically). This system is called webcal.

Chandler Desktop works great for subscribing to a number of public webcal URLs and overlaying them all on one canvas. This is a great way to keep track of lots of calendars.

If you store any events/tasks on Chandler Hub, then you can login to get a URL that you can enter into the right spot in Outlook, Apple iCal, Google Calendar, Lightning/Sunbird, Evolution, Zimbra, and many other apps to synchronize that Hub calendar with your app. This is always a read-only/1-way procedure.

Using webcal, in Outlook 2007, you can overlay say personal or family Hub calendars on top of your Exchange/Outlook calendars you use at work. (Look for “Internet Calendar” features in Outlook’s help.) If you make a change on the Hub or Chandler Desktop and then synchronize, you’ll see that change in your work Outlook’s display.

You can also subscribe to Hub calendars in Outlook 2003, but only view the calendars side-by-side. Other apps like iCal, Lightning/Sunbird, Google Calendar, and Evolution all support overlaying the Hub calendar with other calendars.

Many applications, Outlook included, can also publish a webcal calendar to a web server. You can use Chandler Hub as a destination server for most of these webcal-publishing apps. This works, but please note this does not provide a web UI for that calendar, and it’s again a 1-way publication. The original application will very likely not detect any changes made to this webcal file on the server.

Webcal, 2-way sync

Chandler Desktop can also do 2-way synchronization via webcal. Most applications treat a webcal file as read-only or write-only, but Chandler Desktop will check for changes in a webcal file it is monitoring and integrate those changes. If used with another application that also checks for changes, you get 2-way synchronization. We know Lightning/Sunbird does this (though you might chose to use CalDAV to synchronize instead).

CalDAV, 2-way sync

CalDAV is an emerging standard protocol for open calendar exchange. It’s not a protocol that’s used directly between two clients (like ICS files are), but rather defines a calendar server to which multiple clients can subscribe and synchronize. Chandler Hub also provides a read-write web UI to any calendar you store or use in your account.

The Open Source Applications Foundation via the Chandler Project was an early supporter of CalDAV. Together, our Chandler Desktop application and Chandler Server server product are some of the oldest and most mature implementations of the CalDAV standard and we plan to continue that support.

Chandler Hub is, as far as we know, essentially the leading free CalDAV service offered to the public. Given a fully-cooperating CalDAV client (Lightning/Sunbird, iCal 3.x, and Evolution all cooperate to various degrees), you can use these other clients regularly or occassionally and even use Chandler Desktop for advanced work (like sharing a single item between multiple calendars).

Chandler Desktop can subscribe to and publish a collection (calendar+events) to any CalDAV server (Apple Calendar Server, RSCDS, Bedework), or actually any WebDAV server (Apache mod_dav, .Mac, etc). Both of these mechanisms support bidirectional (read-write) synchronization, so multiple applications or people can all create, edit, and delete events and tasks any time they want, using the application of their choice.

iCal 3 (in Apple 10.5 “Leopard”) is a great new CalDAV-using PIM client. You can use it to make changes to your Hub collection, and still be able to use the Hub web UI to make changes from anywhere. Note that iCal 3 supports read-write calendars only to calendars in your account. Chandler Desktop and Chandler Hub let you subscribe to shared collections owned by other users with full read-write access.

Email integration

Chandler Desktop is not a complete email client; it is rather intended to complement your existing email client. The mechanism we use is to create dedicated Chandler folders on your IMAP server. Using your regular email client (Outlook, Thunderbird, Mail.app, Evolution, etc), you just drag an email from your inbox into a Chandler folder, where the message will be parsed for event, task, and other information.

You should also be able to send email update of items from Chandler Desktop using just about any outgoing mail server available. Events emailed this way appear as ICS attachments. We’ve tested Exchange, Postfix, Gmail, Yahoo mail, and Hotmail/MSN among others.

Mimi described the goals nicely in a post to the chandler-dev list…

1. Get Chandler in front of more users, aka: Make it more viral.

Product changes:

• Item sharing: a new workflow to use the web to collaborate on just one item. We’ll “widgetize” this functionality, making it available in other contexts like iGoogle or on an iPhone.
• Improve web UI “ticket views” so subscribers can more easily subscribe to collections in applications they already use
• Improve existing use cases for iCal and Lightning users (sharing with Chandler users, using Chandler Hub)

Marketing and Evangelism:

• Improve our pitch, improve our web presence
• Better demos, user testimonials
• Reach out and talk to people about Chandler in other spaces

2. Make Chandler more appealing to new users, aka: Reduce barriers to getting started.

Reduce the number of new concepts users need to understand in order to get started:

• Pare down UI, de-emphasizing email UI
• De-emphasize notion of “Item” and replace with “Note”
• Remove explicit “Task” and introduce “Star”

Improve the web UI experience for people not using Chandler desktop (iCal/Lightning or Hub only users):

• smooth out sharing workflows
• auto-triaging CalDAV events
• make Notes field in detail view more usable

3. Make it easier for new users to ramp up to using Chandler every day.

Add two additional “widgets” with features that allow people to use Chandler in other contexts:

• Notifications: Users can send themselves or others notifications about changes to shared collections. This also counts towards the first goal, as it allows current users to share some Chandler functionality with other people. Notifications will be available first as an iGoogle widget (and potentially other similar contexts), and eventually also as email, SMS, or IM messages.
• Quick Entry: this widget will allow users to enter items into Chandler Hub from other contexts: iGoogle, iPhone, OSX and Vista widgets. Eventually we’d like to allow similar functionality through forwarding email to a particular address.

Work Queues and Releases

The work described above has been broken down into tasks and bugs and is prioritized into two work queues, one for the desktop and one for all of the web related work. Grant is marching down the desktop queue while everyone else tackles the web queue. We meet daily to cover progress, adjusting the work queues if priorities change. (Mockups and specs for the new widgets and web UI changes are also linked from the web queue.)

• Web Work Queue
• Desktop Work Queue

The plan is to do a desktop release and a server release once a month. Usually these won’t need to be coordinated — though in this next round we have a security bug that involves both.

Phillip’s work on the desktop rearchitecture is the exception. He’s posting about his work over on the PEAK list. We may move Chandler desktop over to this architecture after the 1.0 — we’re waiting to see how this plays out to make the call on that.

Milestones

We plan on hitting a few major milestones by early summer — these are the big goals we are shooting for:

• Web Widgets: Quick Entry, Notifications, Item Sharing — we’d like to have these deployed in a few contexts.
• Desktop 1.0: We’re pretty close to releasing a 1.0 desktop. Prior to launching this we want to make sure some web UI improvements go up on the Hub, and make some changes to the website.
• Server 1.0: With some security fixes, authentication work, and a few other items (e.g. the ability to disable account signups), we should be able to release a 1.0 for people who want to run their own server.

We don’t need to coordinate all of these milestones — we may hit some more quickly than others.

Changes to the Plan

We were thinking we’d put minimal investment into the existing web ui, figuring that we’d do a better job on the web use cases we want to hit with the web widgets. Once started thinking through both the web and desktop use cases, we realized we really do need to make some investment in the existing web ui. We’ve added web ui bugs to the web queue.

We decided to put off working on a Thunderbird plugin, for two reasons: (1) after doing a bit of research it was starting to look like a more sizable investment than we initially thought and (2) we worried about having too many projects.

The major improvements include:

• Full UI support for Safari browsers
• Multiple fixes to triage status handling between Chandler Desktop and Chandler Server
• Supports browsers set to widths greater than 1600 pixels
• URLs presented for webcal-based downloads now working
• Support for more punctuation characters in titles
• Editing recurring events works better in multiple situations
• Fix for the edited-by column in the dashboard view to show more useful data
• Multiple bugs fixed which were creating user-visible error messages
• Lots of individual feature and visual improvements and bug fixes

Please see the Cosmo blog channel for additional information about each individual release.  More neat features appear on the horizon from new Cosmo development.

As always, we welcome individuals and groups to try the free and open Chandler Hub service in addition to other Chandler Project components.

Chandler Server is a server and Ajax web UI for managing and sharing calendars, events, and tasks. It implements open data standards including CalDAV, WebDAV, Atom, and Atompub.

Chandler Server 0.7.3 is currently available for download as a ready-to-run bundle at:

 chandlerproject.org/serverdownload

and the source code is available from subversion at:

 svn.osafoundation.org/server/cosmo/tags/rel_0.7.3

Send us feedback at the open mailing list:

 chandler-users at osafoundation.org

We look forward to hearing from you!

This is a bugfix release for Chandler Server 0.7.2 and is recommended for general usage.

This release fully supports Apple Safari 2.x

The bugs fixed in this release are:

8088 Changing a recurrence rule in the middle of series should…
10240 Safari Creating new events broken
10491 Dojo isn’t in about box list of technologies
10576 Extra day added to recurring event
10674 unstamping recurring event as stamp leaves modifications …
10751 Modified occurence on a bi-weekly doesn’t show up
10826 Can’t access share with ticket URL
10836 Subscribe with: pulldown displays wrong URL
10872 Duration object doesn’t parse, add weeks.
10883 Selecting items in Dashboard is broken…

A summary of known issues in this release is available:

 chandlerproject.org/knownissues

Thanks for your interest in Chandler Server!