Hi Tom! Thanks for the good questions you are presenting. It's good to come back to the design decisions every now and then to see if they are still valid.
> The use case of applying some dampener algo to a wildly oscillating > raw event source makes sense. Where we apply that logic - AMB vs. > Murphy is not clear to me. For example - the exact same logic applies > to fuelInfo - the fuel tank sensor will oscillate wildly as the > vehicle moves. I think the difference here is the level of abstraction. The FuelInfo property is supposed to reflect as accurately as possible the amount of fuel in the system. No other "policy information" can change the amount of fuel present in the vehicle. NightMode, for instance, can be calculated using a complex heuristic, which can change based on vendor and user preferences. Consider, for instance, a vehicle where there is an interior lamp. Exterior brightness may change, but a case can be made that the NightMode should be off when the interior lamp is on because some screens are more readable that way. Murphy provides a place to configure that behavior, if some IVI vendor decides to implement it that way. Another example: (hypothetical) laws in some country might say that user must not be distracted by bright screen when the time is past midnight. Creating that variant requires just changing the Murphy configuration file. Still one more example: user selects from a settings application that they want the NightMode to be off. Murphy is designed to interface different configuration settings. It catches the user command and promptly overrides the current NightMode setting. For dampening, I think you might mean that the sensors providing the basic information should be dampened? > By policy manager, I mean subscription to events, analysis of these > events changing a state machine, and as one moves states the execution > of a policy. Audio takes the lead use case, but I see a vision to > expand beyond this to other domains. Well, Murphy is not state machine based as such -- it is rule based. When an event comes in, rules are run. But you are right in that one of Murphy's main goals is to be able to combine information coming from multiple domains for decision making. In the case that you are describing, AMB can be considered to be in "automotive domain". > None the less, I always understood the boundary of Murphy was to > "enforce" policy - "Murphy is a resource policy daemon, designed to > do cross domain policy decisions in a configurable way." [1] > 'Murphy's mission is to follow and understand the current system > state and then make decisions triggered by events" [2] > Collation and reporting of events seems to my limited understanding > seem to deviate from that mission. Hmm, I don't see it that way. The fact whether we are in night mode is, in this particular case, a policy decision that Murphy makes. The value is communicated back to AMB so that others can benefit from that information. I don't quite understand what you mean by "enforcing" in this case. > Is message transformation one of the primary design goals of AMB and by > extension should AMB be responsible for controlling and reporting the > NightMode property? The message transformation in this sense means that the information coming from CAN bus is transformed into D-Bus or JSON messages. It doesn't mean that complex policy processing is done. From the "Message Broker" Wikipedia link you provided: "Transform messages to an alternative representation". This is exactly what AMB is doing. Throttling and filtering is an important (upcoming) feature in AMB, though. The best implementation might be if clients could push their own filters and throttles to AMB so that they could receive events on the speed of their own choosing. For instance, a speedometer might need speed events once per second, but some other application might want to be alerted only when the value went over some threshold. Murphy will most likely set its own filters and throttles at some point. > I guess my fundamental question boils down to this - do we have a > cyclical architectural dependency that needs addressing - i.e. moving > what appears to be AMB logic out of Murphy into AMB? So, in short: I think the way responsibilities are shared between AMB and Murphy is still a sound one. Both components are doing what they are supposed to do, and the dependency between the components is minimal. If Murphy is missing, AMB is just not receiving updates for those properties controlled by Murphy. If AMB is missing, Murphy is just not doing decisions that depend on automotive data. Let's not fix things that are not broken. -- Ismo Puustinen <[email protected]> _______________________________________________ IVI mailing list [email protected] https://lists.tizen.org/listinfo/ivi
