persistency enhancement points to dicuss

[Ahmed-Elsaka-JC]

What

i want to discuss the follwoing enhancement points for score-persistency :

• CRUD-APIS : remove_all_keys()
• CRUD-APIS : Discard_pending_changes()
• CRUD-APIS : Get_Storage_file_size()
• Redundancy : KVS_MAX_SNAPSHOT is fixed number
• Corruption : using CRC64 instead of Adler32
• backup : create backup file before open storage file , all backup files deleted before open function called.
• Cleanup persistency : API to remove backup files.
• concurrent Process access : need to be documented if it is possible or not ?? Should be not :) --> should be existing feature requirmenent
• storage access control (Permissions )
• Configuration json file (and priorization, assumption file config overwrites "code config")
• get_value api not return default value , if default value is needed there are another API to get default value.
  --> 2026-08-20: Discussed in FT meeting: Working assumption ... no implicit fallback to default app needs to explicit request if wanted
• support encrypted storage files

Acceptance Criteria (DoD)

take decision for each point .

How

No response

[Ahmed-Elsaka-JC]

proposed jsong configuration file structure.

[christianbe9]

I think
This point: "concurrent Process access" directly influences "storage access control (Permissions)"

My current understanding is that a KVS is unique to a process. Means it cannot be shared (i.e. not concurrent accessed, but not even accessed at all by any other application). Means only one user/uid has access to it, i.e. the one using this KVS.

Now I can think of two usecases who are left over:

(1) You might want to define a "predefined" KVS, i.e. something similar to a configuration, meaning that to generate the kvs offline and might want to only allow this process to read it, in this case the system integrator can define the file as ready only.
(2) The application creates and modifies it on the fly. In this case I would define that whenever the kvs is initalized it automatically generates a file for which only the current invoked uid has read+write access, nobody else.

In this cases we might not even need an "access_mode" defined?

In case we intend to share a kvs, i.e. by locking it, then ofc we would need permissions. I would then like to include this usecase also on the ACL: https://github.com/eclipse-score/score/pull/3058/changes

[Ahmed-Elsaka-JC]

I think This point: "concurrent Process access" directly influences "storage access control (Permissions)"

My current understanding is that a KVS is unique to a process. Means it cannot be shared (i.e. not concurrent accessed, but not even accessed at all by any other application). Means only one user/uid has access to it, i.e. the one using this KVS.

Now I can think of two usecases who are left over:

(1) You might want to define a "predefined" KVS, i.e. something similar to a configuration, meaning that to generate the kvs offline and might want to only allow this process to read it, in this case the system integrator can define the file as ready only. (2) The application creates and modifies it on the fly. In this case I would define that whenever the kvs is initalized it automatically generates a file for which only the current invoked uid has read+write access, nobody else.

In this cases we might not even need an "access_mode" defined?

In case we intend to share a kvs, i.e. by locking it, then ofc we would need permissions. I would then like to include this usecase also on the ACL: https://github.com/eclipse-score/score/pull/3058/changes

i would agree kvs should used only by one process but this is not mentioned in requirements for that reason i added this point.

sometimes we want to use storage file in using read_mode , with this mode application will only be able to read only , but also this is open point to discuss .

[christianbe9]

Definitely we should add this to the requirements - if not already done.

Some question for my brain to further understand the point:

• Do you want to differentiate read and read_write access for usability, or
• Do you want to differentiate read and read_write because you want to assure that kvs is never changed, e.g. only trough SW Update?
• Or alternatively what is the usecase you have in mind for read_mode (simply runtime so that writing is skipped on flush/shutdown/statechange/whateverisdefined)?