The Calendar Data API support (these feeds plus the ability to programmatically create, query, edit, and delete Calendar events) isn't officially launched yet... the release is going to be slightly staggered from the main Calendar Web UI launch that happened today.That's good news. I hope they use WebDAV + HTTP Auth. Or, in an unlikely scenario, it would also be nice if they used the APP.
From home.cwru.edu: Calendaring Survery:
I am doing an English 398N project and as part of that project my group has created a survey to determine the anticipated need and usage of an all-campus event and activity calendar
Some fellow sophomores and I have started an initiative (caleld the DO campaign) to produce a campus-wide activities calendar, resulting from some brainstorming at the Second Year Insitute. We've already approached VP Glenn Nichols about this and even have a programmer to do the coding. We'd be happy to get in touch with you, if you'd like!
It's sad that we have so many "calendars" on campus, and yet, none of them are a good enough service to reach the tipping point where everyone uses them.
Some people, when reading the above, undoubtedly think, "well, what we need is the one true calendaring application that everyone will use!" Other people may think, "we'll just make a University mandate that says everyone has to use this specific calendar." (Because that always works well — dictation to your customers and your users instead of providing them with services that they elect to use.)
When I hear about the problem, I think, "well, if all of the different calendars exposed their data, we could just aggregate them into one 'calendaring space.'" "That is, everyone gets to use their own little calendaring application/service/thing-a-ma-bob, and we provide a service that pulls all of them together for display." Basically, if each separate calendaring service exposed its data in an XML format such as RSS or Atom (or even in just a publicly exposed iCal/vCal format), we could build a service that spliced all of that disparate data together and displayed it in a calendar view. (Yea, this is the essence of Middleware.)
Back in the beginning of this summer when Greg first started working for us, he was supposed to do a project with the calendar.case.edu system. I wanted him to do precisely what I describe above — a calendaring aggregator system. With that framework available, we could both go off and develop plugins for some of the major calendaring apps (like the Oracle Calendar, WebEvents, Exchange, etc.) so that they would emit their data in RSS/Atom. Then, we just aggregate it all together in the calendar aggregator. But, the idea gained no traction and Greg ended up doing something else with the Oracle Calendar (I can't even remember what it was and don't believe it amounted to a deliverable) before he went on to do the Case Wiki and Case Central Authentication Service.
It's too bad the calendar aggregator was never able to get off the ground. Hopefully, the students out there right now talking in the forums can generate an idea like this.
Partial Calendar List (there are so many)
Many people have commented since the upgrade of the calendar that they can no longer reach the web calendar page. Here's the most common reason, and how to fix for the most commonly used browser.
If you can't get to the calendar web page (you get a "500" error) you probably have a browser caching problem (the web calendar page URL moved as part of the upgrade). In that case, here's what you need to do:
First if you are using a bookmarked page, make sure you are connecting to http://calendar.case.edu