W3C home > Mailing lists > Public > public-sysapps@w3.org > May 2013

Re: Alarm API: ignoreTimezone/respectTimezone

From: Mounir Lamouri <mounir@lamouri.fr>
Date: Tue, 21 May 2013 15:47:33 +0100
Message-ID: <519B8905.1070408@lamouri.fr>
To: public-sysapps@w3.org
On 21/05/13 08:20, JOSE MANUEL CANTERA FONSECA wrote:
> El 15/05/13 18:44, "Mounir Lamouri" <mounir@lamouri.fr> escribió:
>> Another side effect of that proposal is that ScheduledTask has to be
>> constructed instead of being returned by the add() method. This is
>> mostly because working with objects seems nicer to me and others are
>> likely to disagree ;). Though, some possibilities that are being enabled
>> by that is to do:
>>  var t = [];
>>  t.push(new ScheduledTask(new Date() + delay, "current", {}));
>>  t.push(new ScheduledTask(new Date() + delay, "none", {});
>>  taskScheduler.add(t);
>> (IOW, it allows getting an array of ScheduledTasks in add().)
>> This said, having a constructor for ScheduledTask would change a bit the
>> id behaviour and every construction should generate a uuid that would be
>> used when saving the object into the database. The backend would no
>> longer return an id matching it needs. I do not think this is terrible
>> but some might disagree.
> I assume that the id attribute will be generated (possibly lazily) once
> the ScheduledTask object is constructed by the platform, right?
> The ScheduledTask id is important for the app as it could be needed later
> for removing the task if necessary. That in practice means that we would
> need a method in the scheduler to remove a ScheduledTask by id.

Yes, that's correct, it will be generated at construction. I think we
could probably keep the string content as an implementation detail but
assigning an uuid to the id would be good enough IMO.

Received on Tuesday, 21 May 2013 14:48:00 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 1 July 2021 16:04:43 UTC