Explicit cleaning of rafcon- and handling of user- or plugin-meta-data

[franzlst]

This issue derives from issue #354. Here data was found that is no more in use but which was screwing code that was working before. Start to read the last comments there and continue here.

Finally @bruns-sb and me came up with the explicit handling of this data by introducing two sub-dictionaries 'plugins' and 'stored_data' that are supported and all others will be removed and thereby old RAFCON data will be cleaned in future automatically.

User will have to move there data to respective fields to save them. Therefore we have to discuss further how we deprecate current options of storing meta data that freely.

Originally created by @Rbelder at 2019-01-15 16:57:29+00:00 (moved from RMC internal repository)

[franzlst]

Could you please give some more information, where these "sub-dictionaries" plugins and stored_data are located in and how they are filled?

Remember that meta data of the graphical editor is currently stored in ['gui']['editor_gaphas'][key]. Outdated meta data is e.g. ['gui']['editor_opengl'][key]. The OpenGL meta data are right now automatically converted to Gaphas meta data and deleted afterwards.

Currently, it would be possible for a execute script of a state to store information in the state's meta data, which would be stored on state machine storage. This would no longer be possible, right?

I don't really see the reason why the meta data should be cleaned. If meta data is "screwing code", I could imagine that the code is false. Or can you give an example of well-written code that gets screwed by meta data?

Originally created by @franzlst (Franz.Steinmetz@dlr.de) at 2019-01-16 08:35:23+00:00 (moved from RMC internal repository)

[franzlst]

In my opinion a user should not be able to arbitrarily screw up the meta_data dict. Of course, there should be entries like "plugins" and "private_state_data" where the user can do custom stuff.

Another reason if, that we can keep the format of meta data clean and consistent especially for old state machines.
Let's discuss this in the next meeting.

Originally created by @sebastian-brunner (Sebastian.Brunner@dlr.de) at 2019-01-16 08:44:25+00:00 (moved from RMC internal repository)

[franzlst]

Currently, it would be possible for a execute script of a state to store information in the state's meta data, which would be stored on state machine storage. This would no longer be possible, right?

By the way this is not really correct. The meta data is provided by rafcon instances if the models were generated. Otherwise the script will initiate the dynamic creation of models and loading of meta data (imagine what will happen - most likely and error and freeze). And we have the aim that the models are actually not generated if the rafcon_core only is run. So if you name it the execute script take into account that it is not that simple.

So at the moment it would be much easier to use the semantic data to store your additional information. The question is more will or is anybody using this not explicit documented option to store data via the meta_data.json. I doubt it seriously.

I don't really see the reason why the meta data should be cleaned. If meta data is "screwing code", I could imagine that the code is false. Or can you give an example of well-written code that gets screwed by meta data?

It is not about the code it its about an explicit interface for data that is documented at the end. Let the screwed code go. It is fixed and is not a topic of this issue. If you wanna see and example I could imagine that there will be one within the next 6 month which occurs in the gaphas editor. 😄

Originally created by @Rbelder at 2019-01-16 09:16:34+00:00 (moved from RMC internal repository)