specification Notification Acknowledgements

We should be able to acknowledge notifications, so that if multiple consumers are seeing the notification, you don't need to acknowledge it on each one by one.

I suggest a new optional value under the "notification" definition called "acknowledged".

Value would string enum with possible values true/false. If it is not existing under the notification object clients should assume false. It should have $source and timestamp as well.

I suggest also adding a way of expiring an acknowledgement. Maybe an optional timeout/ttl metadata field?

Also, server should either remove ack object (or set to false) if alarmState changes. (like from warning to alarm) I would assume it would send to delta's to consumers, first removing ack, (or setting it to false) and second is the new state.

Thoughts? I'd like to give a go at doing the pull request for this one if people agree it's a good idea. I'm still a somewhat junior developer (dayjob is networking) and am looking to learn :)

Sep 06 '17 16:09 mxtommy

I don't actually see the need for acknowledgments. The way I do this is by changing the notification method

Sep 08 '17 19:09 sbender9

@sbender9 if it is a reoccurring alarm, like pgn 127489, won't it be reset when the next pgn is received?

Sep 10 '17 18:09 tkurki

Forgot about that. Yes. That's an issue now. But would still be an issue if we added acknowledgement, right?

Sep 10 '17 19:09 sbender9