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

On Tue, Feb 12, 2013 at 3:16 AM, Marcos Caceres <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 ;-))

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.

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. For example whether we make the API sync or not is
unaffected by if it takes a data argument. 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.
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.

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.

The main overhead implementation-wise is calling the JSON serializer
during the .add() call, and the JSON parser during the firing of the
callback. 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).

/ Jonas

Received on Friday, 15 February 2013 05:24:00 UTC