Thanks for the pointer. What flavors of RSS representation of calendars does it support?

It’s also interesting that you’ve done this using RSSBus. I interviewed the company’s founder, Gent Hito, here: http://blog.jonudell.net/2007/05/05/a-conversation-with-gent-hito-about-rssbus-and-the-data-web/

Love the concept.

Thanks for the pointer. What flavors of RSS representation of calendars does it support?

It’s also interesting that you’ve done this using RSSBus. I interviewed the company’s founder, Gent Hito, here: http://blog.jonudell.net/2007/05/05/a-conversation-with-gent-hito-about-rssbus-and-the-data-web/

Love the concept.

1. I select one or more calendar items in my calendar program of choice (Say, Outlook)

2. I choose “publish as .ics to Web” and it creates an .ics file for each event, one for all the selected events, and either an XHTML page, “pure” XML page, or a feed which references them. During the publication process a stylesheet can be chosen or created.

If it’s _easy_ to publish calendar events to a web page or blog, without having to understand the underlying standard for the data, then more people will do it. I believe vCard (with the same basic origins as iCalendar) has overcome this hurdle, so iCalendar should be able to do it.

Absolutely. Almost every app benefits from both cloud storage, and cloud-based deployment.

What’s hard to convey to people, whether or not the interactive piece of the calendar app is cloud- or client-based, is that the data has to be cloud-based so that syndicated network effects can occur.

Regarding:

> The iCalendar specification grew out of a
> need for interdepartmental and
> inter-company scheduling, and does not
> have adequate support for events
> intended for a public audience.

This reminds me eerily of the RSS wars that produced so much heat and so little light. Yes, RSS was “underspecified”. And yes, Atom now is (justifiably) ascendant. But no perceived or actual limitations of RSS prevented it from spreading the meme of personal-publishing-plus-syndication. Nor do any such limitations account for the failure of that meme to fully propagate.

To me, in these respects, iCalendar is very analogous to RSS. Committee work can and should be done, but iCalendar’s perceived or actual limitations are not the critical bottleneck for public calendaring We need to propagate the personal-publishing-plus-syndication meme in the calendar domain. Most of the necessary ingredients are in place, and the key missing one — aggregation services — can be layered onto the existing deployed standard.

http://www.calconnect.org/tc-eventpub.shtml for more info.

Chuck may be able to give you more info. He is at least a good person to talk to about this area.

I have been playing with the scheduling/calendar app Remind lately, which I really like. My issue with it is that its not in the cloud. I really think email, calendar, and to-do lists work better in the cloud, at least for me.

I like Remind because it can let me do things on my machine (Ubuntu), and its smarter about setting events. I could give up on the capability to do things on my machine, I can always just use Remind for that, but I really don’t want to give up having my calendar/to-do list in the cloud and they really aren’t the same thing.

I think my ideal calendar app in the cloud would be Python based, where each event is stored in a Python dictionary, or a function that returns a dictionary when passed a date. Simple events can be entered with the GUI, like existing calendars, but it would be nice to be able to write a function to allow complex entries.

So for now, I’m stuck using GCal.