What are the reasons for this? It causes massive amounts of work for us, because we have been using Bandana a lot (as well as Active Objects and PluginSettings).
PluginSettings are mentioned as an alternative. Unfortunately, they (a) lack a function like getKeys(bandanaContext), (b) we need to serialize ourselves because they only support a very limited amount of types, and (c) they have limits for key and value length: PluginSettings (Shared Application Access Layer API 3.0.0 API) – are those limitations still correct? Are there plans to change anything about them?
Additional question: I read somewhere that Bandana and PluginSettings access the very same data in storage. I.e. data written by Bandana can be accessed by PluginSettings and vice versa. Is that correct? If so, can we rely on that in the future? Or in other words: Can we safely switch from Bandana APIs to PluginSettings APIs without any data migration and still have all data as before?
Unfortunately, Bandana is by design, not performant or scalable and hurts the stability of large instances.
I will look into whether adding such an API is viable and get back to you.
That is correct, it only supports String, List<String>, Properties and Map<String, String>. Although, the current implementation does not correctly enforce the generic types, which will be rectified in 10.0. You are indeed free to leverage any other serialization mechanism you deem suitable.
Those limitations are correct and similar to those of Bandana.
PluginSettingsFactory/PluginSettings is currently backed by Bandana and so this is correct currently. This will no longer be the case from 10.0; however, we will copy across data which is compatible (that is values of types String, List<String>, Properties and Map<String, String>). Values of other types will be read-only from Bandana for the life of 10.0 before its permanent removal.