Subject: [lmap] reporting the event that triggered the execution of a schedule

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 12 Aug 2016 11:03:05 +0200

Hi,

during the last IETF, we discussed whether we should report the event
that caused the execution of a schedule. I think this issue was
initiall raised by Gert Grammel (according to the minutes).

With the given model we have, I do not think we need to make any
changes. The reason is that a schedule is bound to exactly one event
source, that is, we do not support that multiple event sources trigger
a common schedule. Since we report the schedule name in the result
records, the event source is implicitely known. Hence I sugggest to do
nothing (unless we want to allow multiple event sources to trigger
schedules, which would be a more substantial change).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 14 Aug 2016 07:25:42 +0000

> -----Original Message-----
> From: lmap [mailto:[email-masked]] On Behalf Of Juergen
> Schoenwaelder
> Sent: Friday, August 12, 2016 12:03 PM
> To: [email-masked]
> Subject: [lmap] reporting the event that triggered the execution of a
> schedule
> 
> Hi,
> 
> during the last IETF, we discussed whether we should report the event that
> caused the execution of a schedule. I think this issue was initiall raised by
> Gert Grammel (according to the minutes).
> 
> With the given model we have, I do not think we need to make any changes.
> The reason is that a schedule is bound to exactly one event source, that is,
> we do not support that multiple event sources trigger a common schedule.
> Since we report the schedule name in the result records, the event source is
> implicitely known. Hence I sugggest to do nothing (unless we want to allow
> multiple event sources to trigger schedules, which would be a more
> substantial change).
> 
> /js
> 

OK with this proposal. 

Dan

(as contributor)