To me the W3C DAP calendar is a reworked BONDI calendar, which simply misses the mark for me. Nevermind the proposed added complexity and the “god knows how” the two APIs are going to converge, lets start at the beginning.

The DAP defined use cases:

• A web application would like to access the device calendar
• A user would like to create/modify/delete a Calendar appointment
• A user would like to enter a birthday of his friend with a recurrence event
• A user would like to set a reminder for upcoming events.

Lets distil what we are trying to do. Because I for one don’t care about the calendar of my mobile device (who does?). I care about the calendar on my Web service http://calendar.google.com. I find out about friends’ birthdays on http://facebook.com. What I want my personal mobile device to do, is to remind me about those events in my calendar.

How does one get reminded? The way I have been doing it for years is setting alarms on my personal mobile device.

Alarms to wake up. Alarms to go to my dentist appointment. Alarms reminding me about my Mother’s birthday. The most basic alarm just sounds or vibrates the phone at the start of the appointment. More advanced alarms could notify you (in advance) in a variety of ways.

So what I am saying we don’t need a calendar API, we need a reminder API. A good clean native API implementation on an Android smartphone looks like:

The dreaded repeating UI is very simple and it just works for most cases. I’ve done this before.

The easiest way to implement this natively is to leverage cron, for example:

# m h  dom mon dow   command
35  7  *   *   sun         alarm
30  6  *   *   mon         alarm
5   7  *   *   tue,thu,fri alarm
40  6  *   *   wed         alarm+vibrate
0   8  *   *   sat         alarm

The “Alarmed” Calendar WebIDL

interface Alarm {
attribute DOMString name;
attribute DOMString m;
attribute DOMString h;
attribute DOMString dom;
attribute DOMString mon;
attribute DOMString dow;
attribute DOMString action;
};

interface AlarmFilter : Alarm {};

typedef sequence<Alarm> AlarmArray;
typedef sequence<DOMString> StringArray;

interface Callback {
  void call(Object ob);
};

interface AlarmManager {
 void set(Callback c, AlarmArray alarms);
 void get(Callback c, [Optional] AlarmFilter filter);
 void del(Callback c, [Optional] AlarmFilter filter);
};

Using man 5 crontab as a guide, lets set an alarm for getting up for work:

navigator.alarm.set(
	function(ob) {
		if (ob instanceof Error) { alert(ob); }
		else { alert("Alarm(s) set " + ob); }
	}, [{ name:"wakey wakey", h : "7", dow: "1,2,3,4,5", action: "sound"}]);

Lets sync our alarms with our service in the cloud, like so:

$.getJSON("http://calendar.example.com/?auth=" + auth + "&callback=?",
	function(data){
	navigator.alarm.set(
		function(ob) {
			if (ob instanceof Error) { alert(ob); }
			else { alert("Alarm(s) set " + ob); }
		}, data);
	}

If I leave out the filter, I mean all:

navigator.alarm.del(
	function(ob) {
		if (ob instanceof Error) { alert(ob); }
		else { alert("All alarm(s) deleted " + ob); }
	});

navigator.alarm.get(
	function(ob) {
		if (ob instanceof Error) { alert(ob); }
		else { alert("Active alarm(s)" + ob); }
	});

Hell, you could implement this cron in Javascript if you had HTML5 audio and some UI vibrate and flash goodies at your disposal.

I also think it’s important to have a mapping to a RestFUL API, for example:

POST /set
Req: {{ m: "*", h: "*", dom: "*", mon: "*", dow: "*", action: "sound+vibrate+flash" }}

Res: [ 1 ] // affected ids or name

POST /get
Req: { m: "*", h: "*" }

Res: [
		 { m: "*", h: "*", dom: "*", mon: "*", dow: "*", action: "sound+vibrate+flash" },
		 { m: "*", h: "*", dom: "*", mon: "5", dow: "*", action: "sound+vibrate" }
	]

POST /del
Req: { "1", "wakey wakey" }

Res: [ "1", "wakey wakey" ] // affected reminder ids/names/labels

That way I could send an alarm set request (with some auth magic) on my mobile’s httpd endpoint at for example http://192.168.1.10/alarm/set without even touching my mobile device.

Please let me know what you think.

Cons:

• The Android “clock” interface I said was great can’t actually describe a cron job accurately. However, the repeating UI could be extended for simple representations of ’m,h,dom,mon'
• Cron has issues like not knowing holidays and stuff like that. I guess a clever implementation could mark this.