On Wed, 11 Jan 2017 10:57:56 +0100 Norman Feske <norman.feske@...1...> wrote:
That said, if you have a tangible use case to propagate update signals for disappearing reports, I have no principle objection against it. But I would like to understand the use case. Can you describe the scenario where the current behavior caused you trouble?
Sure. The scenario consists of two report_rom components. Let's call these config_rom and report_rom. The report_rom gets its config from the config_rom so that it can be changed dynamically by a management component that reports this config to the config_rom. On session request, the report_rom implementation calls an update() on its ROM session to the config_rom before looking for a matching policy. The problem was triggered by the fact that the management component (unintentionally) released the report session after some time. Hence, the update() in the report_rom refreshed the dataspace of the ROM session to the zeroed-out/empty version.
I don't have a problem with this behaviour in this particular scenario as the report session must be kept alive for the lifetime of the management component anyway. However, it raised the question (to me) whether the config_rom should deliver an invalid dataspace instead of a valid but empty dataspace. I think, depending on the report/application, an empty dataspace can for sure be considered valid. Nevertheless, I have the feeling, that there should be a difference whether an empty report has intentionally been reported or whether the report_rom emptied the dataspace after the report session has been closed. Or to put it another way: Initially, i.e. if no report session was created (yet), the report_rom delivers an invalid dataspace to the ROM clients. Shouldn't the report_rom restore this state after the report session was closed?
Cheers Johannes