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

On Friday, 15 February 2013 at 05:23, Jonas Sicking wrote:

> On Tue, Feb 12, 2013 at 3:16 AM, Marcos Caceres <w3c@marcosc.com (mailto:w3c@marcosc.com)> wrote:
> > 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
>  
> The data is "just" a convenience function (just like the .then() function ;-))
Again, I was not advocating DOMFuture … I'm just trying to avoid another tirade of angry developers screaming "this sucks" ;)  
> It's definitely true that we could require that the application uses
> the returned ID as a key into a database which stores the information
> elsewhere.
>  
> However it doesn't simplify the implementation meaningfully to remove
> the data argument. In either case the implementation will have to
> store the date and the ID into a database backend of some sort. So the
> addition of an extra string argument (the JSON serialized value)
> doesn't change what actions the implementation takes.

It may not (and that's an implementation detail), but you are forcing everyone else to who might implement this into creating a new database store that also needs to cope with the "data". It also pollutes the platform, adds a new place for privacy issues, more complexity, etc. The fact that we are adding a persistent key for this API is a necessity, but adding data to the end of that is not.
> In either case we are stuck with an additional database backend of
> some sort. With all the privacy and performance implications that come
> with that.

What's the privacy implication if storing a key that refers to an alarm?   
> For example whether we make the API sync or not is
> unaffected by if it takes a data argument.  

That's not what is in question. Adding all the DOMRequest baggage to make this work sanely is what is in question (as well as other parts of this API that are inconsistent - like sometimes working with Alarm objects and other times working with IDs). This API is just a slightly more fancy version of setTimeout() - I'm asking us to explore alternatives to making this easier to use.
> The reason we made the .add
> function async in FirefoxOS was two-fold:
>  
> 1. We could do the writing asynchronously after having returned an ID,
> however that would remove the ability to guarantee that the data was
> persisted before indicating success to the caller. I.e. we would have
> no recourse if writing the entry to the database resulted in an IO
> error.

Sure. That is not in question.    
> 2. Generating a unique ID can be hard to do synchronously once you
> consider that an application might be running in multiple processes at
> the same time. You couldn't for example use a simple counter.

Sure, but there are many alternatives. What are you using in B2G?    
> Likewise, all the questions about "how does this interact with a
> 'clear private data' feature" remain even if no data argument is
> written to disk.

Sure, but not relating to the data itself.   
> The main overhead implementation-wise is calling the JSON serializer
> during the .add() call, and the JSON parser during the firing of the
> callback.  

You could just require the developer to do that, as you would with localStorage (and probably IndexedDB).   
> I definitely think this is worth it given the saved
> complexity of having to keep two databases in sync (the Alarms API and
> the localStorage/IDB API).
>  

I respectfully disagree. For the reasons I've outlined (privacy, complexity, and consistency), I think the platform should not have additional/unnecessary data stores. If the use cases can't be met with localStorage and IndexedDB, or data actually played some meaningful role in the system, I could be convinced otherwise.

I don't have a stake here (apart from a user's perspective), but hopefully other implementers are willing to put in their two cents.  
--  
Marcos Caceres
http://datadriven.com.au

Received on Friday, 15 February 2013 08:14:22 UTC