RE: [Alarm API] data … yet another DB?

Hi Marcos,

For context, you are referring about the "data" argument of this method:
>  AlarmRequest add(Date date, TimezoneDirective respectTimezone, optional Object data);

I have given this some thought and I tend to agree with you. It seems to me (as well) that the client application could just as well use localStorage or IndexedDB to achieve this. I personally do not see any real advantage in using this data argument (over a database API) except maybe convenience. As you rightfully mentioned though, this convenience has a price.

As a consequence, I would be in favour of removing this "data" argument unless someone has a use case for it that cannot be satisfied by existing Database APIs. Does anyone have any thought on this?

Kr,
Christophe Dumez.
________________________________________
From: Marcos Caceres [w3c@marcosc.com]
Sent: Tuesday, February 12, 2013 13:16
To: public-sysapps@w3.org
Subject: [Alarm API] data … yet another DB?

I've been looking at the "data" option of this API and I'm a bit concerned that it adds yet another database/datastore to the platform. I'm wondering why localStorage and/or IndexedDB are insufficient that this API requires its own long lived datastore? Given that Alarm objects as currently specified have a long-lived identifier, can't that identifier be used to associate the alarm's data in either localStorage or IndexedDB?

I could see the rationale for sending data to the platform if the platform was then able to do something meaningful with that data. For example, if the data contained a message, and that message was displayed to the user independently of the application (although that doubles as a notification or just using an alert).

I've also noted some of the privacy concerns I have with this additional data store [1]. Having data only stored in the currently designated places of the platform allows us to better manage privacy as well as gets rid of yet another potential attack vector.

[1] http://lists.w3.org/Archives/Public/public-sysapps/2013Feb/0019.html

--
Marcos Caceres
http://datadriven.com.au

Received on Tuesday, 12 February 2013 14:34:36 UTC