Re: Web Alarm API - idiomatic check

On Wed, May 8, 2013 at 4:32 PM, Allen Wirfs-Brock <allen@wirfs-brock.com> wrote:
>
> On May 8, 2013, at 3:42 PM, Jonas Sicking wrote:
>
>> On Wed, May 8, 2013 at 11:46 AM, Allen Wirfs-Brock
>> <allen@wirfs-brock.com> wrote:
>>> It isn't clear to me why the AlarmManger methods need to be asynchronous.
>>
>> Because the alarms need to be persisted across system restarts which
>> means that they need to be saved to disk. Any disk access from the
>> main thread always needs to be async.
>
> Is it essential that the write completes before execution continues or can it be handles as a lazy write-behind?

You could do a lazy write, but for .add() we also need to generate a
unique ID which means that we have to do cross-process communication
which is generally also something that can take long enough that it's
better to do async.

> It would seem that as long as the "application" is still actively running added alarms could be immediately available, even if the disk save has not completed.  It's only when an "application"  terminates/suspend that should really be necessary to wait for these writes to complete.
>
> If the persistent backup of the alarms can be made unobservable, then alarm management could be synchronous which would be a great simplification.

Getting the list of alarms definitely needs to be an async operation
since that requires IO before we could have any type of result. So
even if we made the writing functions synchronous, getting needs to be
async.

> I can imagine you arguing that when an application is resumed, a disk access may be needed before alarms can be accessed.  A way around this, would be to provide an asynchronous "open" call to the alarm manager but then for all operations upon an open alarm manager to be synchronous.

The problem is that the same page could be open in two separate tabs
which are running as two separate processes, so caching locally
doesn't really help.

We could potentially create something that only blocks on
cross-process communication in extreme cases and otherwise provides
results that are no more stale than the current API produces. But is

openAlarms().then(alarms => { console.log(alarms.add(...).id) });

really simpler than

alarms.add(...).then(res => { console.log(res.id) });

Implementation-wise the latter is significantly easier since you don't
have to keep up-to-date per-process caches, but that's something that
I think we could deal with if it's really beneficial to developers.

/ Jonas

Received on Wednesday, 8 May 2013 23:55:05 UTC