eclipse-archived / unide

Eclipse Public License 1.0
29 stars 17 forks source link

Machine-message v3, add "state" field to Message properties #46

Closed joeyphant closed 4 years ago

joeyphant commented 5 years ago

An additional field should be added to determine the state of each individual message in the payload.

suggested name: state suggested type: enumeration suggested values: NEW, ACKNOWLEDGED, CONFIRMED

Especially when talking about machine errors different states are required:

ameinhardt commented 5 years ago

Hi @joeyphant, I like that idea. Is the message itself in a state or would it be a cause or trigger? I understand that a state that is reported appears and disapears (binary). If we use an enum, how do we come to a complete list? E.g. wouldn't we than also have to discuss many other options like ABORTED, REVIVED, REJECTED...

joeyphant commented 5 years ago

Hi @ameinhardt, I would say the message itself is in a state and has different transitions from one state to another. So a state only disappears if another state is set.

While you are right about the discussion on other options, I am not sure what the alternative to an enum would be. Using a string field? Should we not rather start with a first set of options and extend that in the future if additional options are required/requested by someone?

muelsen commented 5 years ago

Hi @joeyphant , @ameinhardt , for me it would be sufficient to have to START/STOP or ON/OFF information as @ameinhardt mentioned by the binary option. There will be also other states depending on individual use cases and manufacturing types, but covering them all won't be possible. So let us start with the binary version (e.g. START/STOP)

ameinhardt commented 5 years ago

@muelsen: state already has a meaning. I would prefer to coin a different key for this attribute like cause, trigger or side. What do you think?

joeyphant commented 5 years ago

@ameinhardt , @muelsen : we had a very similar discussion internally before actually making this request. While a binary "start/stop" option would be enough for our current usecase, we did not want to limit others (and ourselves) to only use those two options. A binary option could still be introduced following my original request (only allowing NEW and CONFIRMED), but would still allow us to extend it later.

muelsen commented 5 years ago

@ameinhardt , I thought state is only OK, WARN, INFO, ERROR or UNKNOWN, not? @joeyphant , NEW would be also OK from my side, but with CONFIRMED I assume an action (e.g. by the operator). In some case maybe there is not action, just end of the failure. Is there maybe a synonym for this?

joeyphant commented 5 years ago

OK, WARN, INFO, ERROR and UNKNOWN are possible states of the device (device.state with enum type DeviceState). I don't think we should use a different word if we want to describe the state of a message.

Possible synonym for CONFIRMED: ENDED, FINISHED

ameinhardt commented 5 years ago

Hi @joeyphant, I would like that there is no synonyms but well-defined states. Can you propose a finite-state machine for messages with clearly defnined names and description?

joeyphant commented 5 years ago

@ameinhardt, Considering my initial idea, your input and @muelsen doubt about the word "confirmed" I would recommend the following states:

Name Description
NEW Indicates a new occurrence of this message (e.g. the error is active)
ENDED Indicates that the message was confirmed/resolved by an operator or "just ended" without an explicit action by an operator (e.g. the error is inactive)

Transitions are only allowed from NEW to ENDED and from ENDED to NEW. This also covers the binary usecase mentioned by @muelsen and can still be extended by additional intermediate states.

ameinhardt commented 4 years ago

hi @joeyphant, I added your suggestion in the schema. Thanks for the patience