- From: Kis, Zoltan <zoltan.kis@intel.com>
- Date: Wed, 13 Feb 2013 23:00:36 +0200
- To: Mounir Lamouri <mounir@lamouri.fr>
- Cc: public-sysapps@w3.org
On Wed, Feb 13, 2013 at 10:42 PM, Mounir Lamouri <mounir@lamouri.fr> wrote: > On 12/02/13 14:34, Christophe Dumez - SISA wrote: >> 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? > > The reason this was used in our design is that it was said to be more > "developer friendly" in the sense that developers could simply store > data they need to get when the alarm would go (like the event name and > id in the app DB). I think this is a valuable feature, and we should not remove it just because we cannot easily find a properly formalized way to describe it. Anyway the implementation matters. > > I do not know if that would be that useful to developers and we should > probably look at how Firefox OS is using that information. Given that > it's the last argument, I wouldn't mind having it removed and added > later as optional. > Should we give it a chance still? Even if you postpone for later, someone will have to think it through anyway. Unless the problem solves itself, we should try to solve it now :). Best regards, Zoltan
Received on Wednesday, 13 February 2013 21:01:12 UTC