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.

--
Mounir
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