Hi Johannes,
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.
thanks for the explanation.
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.
Usually, reports have the form of XML with the report name as top-level node type. So in this common case, the report consumer may check for this condition, e.g., to see if a pointer report as issued by nitpicker is valid, one may do:
if (_config.xml().type() == "pointer") ...
If nitpicker closes the report session, report_rom will clear the dataspace. So the dataspace will start with a 0 instead of the top-level XML node. In this case, the 'Attached_rom_dataspace` returns the '<empty/>' node. In the hypothetical case that a valid report is called "empty", one could still check whether the dataspace contains a null-termination at the beginning:
if (_config.local_addr<char const>()[0]) ...
In short, it is already possible to distingish both cases, isn't it?
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?
You raise a good point. But instead of confronting the ROM client with an invalid dataspace (which most ROM clients do not anticipate and therefore don't handle), I would rather deliver a zeroed dataspace initially to achieve the desired consistency. Thanks for pointing out this current deficiency!
Cheers Norman