- From: Mounir Lamouri <mounir@lamouri.fr>
- Date: Tue, 21 May 2013 15:47:33 +0100
- 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