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

Hi,

Zoltan, why are you saying this is a valuable feature?
Do you have any use case where a Database API (IndexedDB or LocalStorage) would not be a suitable replacement?

Unlike what your statement suggests, the main argument to remove the "data" argument is not that we "cannot easily find properly formalized way to describe it". It is because there is a existing alternative that would fit the same needs.

Kr,
Christophe Dumez.

________________________________________
From: Kis, Zoltan [zoltan.kis@intel.com]
Sent: Wednesday, February 13, 2013 23:00
To: Mounir Lamouri
Cc: public-sysapps@w3.org
Subject: Re: [Alarm API] data … yet another DB?

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:10:38 UTC