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

On Wednesday, 13 February 2013 at 21:41, Kis, Zoltan wrote:

> On Wed, Feb 13, 2013 at 11:10 PM, Christophe Dumez - SISA
> <ch.dumez@sisa.samsung.com (mailto:ch.dumez@sisa.samsung.com)> wrote:
> > Zoltan, why are you saying this is a valuable feature?
>  
> I was referring to the functionality itself, and because it may also
> be a common pattern with other API's.

Creating a persistent/long-lived object in the platform is certainly not a common thing. Only cookies, Web Storage, and IDB do this (chrome supports FileWriter, but no one else seems to so I'm discounting it).    
> When I set an alarm, I would
> like to associate it with a context which I want to fetch later.

Sure, you can already do that with its id. You just put that into localStorage or IDB along with the associated data.  
> > Do you have any use case where a Database API (IndexedDB or LocalStorage) would not be a suitable replacement?
>  
> If you put it this way - yes, a DB API can even replace many sysapp
> API's too ;).

With all seriousness, if any APIs can be implemented already by the Web platform, then they should not be standardised. That would be a waste of our time. SysApp's APIs should enable something new in the platform.  
> But it depends on how are you going to use the storage, which still
> needs to be specified.

Who is "you" in the above? Obviously, you can't specify how the developer uses the data (just that they get/set it). If "you" is an implementer, then, yes, you need to specify that, along with all the potential security issues, privacy issues… while keeping in mind all the regulatory issues that could arise (look at the regulatory mess cookies have made). Even localStorage got a lot of bad press as a new, more evil, super cookie.  
> > 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".
>  
>  
> I felt we know what is the use case, but since there was some
> controversy on how to specify it, it was suggested to drop the use
> case for later consideration, which is not the good outcome IMO.
>  
> > It is because there is a existing alternative that would fit the same needs.
>  
> I see the privacy argument stronger. Is it solved by the DB?
There are mechanisms in place in user agents to examine and purge the contents of IDB, etc. These are still evolving. Those would all need to be replicated again for this API. Also, some problems can't be solved, but they are bad enough as it is. Please see for the potential threats to privacy from IDB alone:
http://www.w3.org/TR/IndexedDB/#privacy

Most of which mirror the localStorage issues:
http://www.w3.org/TR/webstorage/#privacy

And, also the cookies ones:
http://tools.ietf.org/html/rfc6265#section-7
http://tools.ietf.org/html/rfc6265#section-8

> Does it
> prevent the misuses enumerated before?

No. But it gives us a single point of focus for that on the platform to mitigate those issues (technically and legally and for user control).  
> Is it as easy to use?

Depends. The architectural problem at hand is that we already have a few persistent data stores for the platform (and these cause us enough - technical, legal, and usability - pain as it is). We should deal with the ease of use problem at the source (IDB or Web Storage) as opposed to routing around it with this API. Additionally, if the current API makes it impractical to work with localStorage or IDB, then the Alarm API should be changed (not to give it storage capabilities, but to make it practical to get a piece of data that can be used to associate the alarm with IDB and localStorage - i.e., make it easy to get the "id" value).  

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

Received on Thursday, 14 February 2013 12:51:36 UTC