Hi Tom! I'm snipping away some parts we have already gone through. Especially I believe we both now understand the current design quite well, and there are no misconceptions in how Murphy and AMB interact. I think message thread contains also some long-needed documentation about the subject together with rationale. :-) The discussion is clearly going more into more philosophic questions, which is fine.
> Murphy indeed today may have an easy way to handle this adaptive rule, > but my question is why would AMB not be the logical place that should > execute instead. It has a plugin mechanism, so could someone create a > 'time' plugin and deliver the info in there? Murphy and AMB are both pieces of open source software running on roughly the same layer in the system. In principle, both can execute arbitrary code inside their plugins, and definitely someone could write a "time" plugin for AMB to get the current time. However, I think that the reason we do have a number of middleware components (such as Bluez, PulseAudio, Systemd, Connman, ...) is that it makes sense to let every component handle their own problem domain and then let them interact wherever needed. AMB is doing its job brokering messages, and Murphy is in turn doing policy decisions. I may be repeating myself here, but in my opinion things are working quite well now. Monolithic designs (in the extreme case embedding system services inside kernel for less data copying and context switches) have been done in the past, but the trend nowadays appears to be towards a relatively clear separation of problem domains into separate processes. Systemd is in some sense an exception to this rule. The "time" plugin case can be generalized to a case where information that is not belonging to "automotive domain" is needed to do policy decisions. It would be stretching AMBs charter to demand it to do policing which can get arbitrarily complex. Murphy, however, has facilities to do exactly that -- it is configurable, gathers data from several sources, has mechanisms to interact with a number of services in the system, and has a well-defined way of doing data processing chains. The Murphy decision logic can be written as easily modified Lua code, C code, or a combination of both. Even if NightMode and DrivingMode calculation is simple now, in the future those calculations are expected to become more complex and especially to depend on vendor configuration. Murphy is well suited to handle cases like these and possibly also other more complex properties in the automotive domain, should those be identified. > I guess what I am struggling with here - using the NightMode as an > example - is NightMode really making applications comply with a policy, > and if so what is the policy. I'm only seeing a property value change > at the moment. "Enforcing" in this particular sense is a bit misleading word, because obviously Murphy can't enforce anyone to behave as if it was night time. Murphy can just tell the results to the world, and hope that everyone who needs this information will use it. Only in some components (such as PulseAudio) which feature close Murphy integration can Murphy do real enforcing. I'm trying to come up with a better way of thinking about "policy". Maybe "policy" is not something that needs "policing" but rather something that is configurable and affects the behavior of components in the system. For example, audio policy can be configured to stop media players when car navigator is doing an announcement. The NightMode policy can be configured to ask the web applications to switch to night time CSS files when the system is thought to enter night mode. > > Murphy will most likely set its own filters and > > throttles at some point. > > Can you expand ? I just meant that when AMB filters and throttles can be configured from outside, Murphy will set conservative filters to limit the information flow to the minimum Murphy needs to be able to make good decisions. -- Ismo Puustinen <[email protected]> _______________________________________________ IVI mailing list [email protected] https://lists.tizen.org/listinfo/ivi
