I fully agree that we need to rethink KEY_FLAG_SYNC. How can we proceed in that matter?

solution would be that plugins create internal

Yes, probably it was a mistake from the beginning to use origvalue for that. The values should be internal as they actually are specific to the plugins.

I fully agree that we need to rethink KEY_FLAG_SYNC. How can we proceed in that matter?

I didn't suggest any changes to KEY_FLAG_SYNC and I think there have to be (at least) two different flags. The replacement for origvalue suggested above needs a flag that exclusively indicates, when the value has changed/is new.
KEY_FLAG_SYNC indicates when a key has changed in any way, such that it has to be written out during kdbSet.

The values should be internal as they actually are specific to the plugins.

The problem, was that the current solution needs the core to remove origvalue on keySetString. It would be weird if the core was aware of internal metakeys for certain plugins. The new solution avoids this.

suggested above needs a flag that exclusively indicates, when the value has changed/is new.

This was the initial purpose of KEY_FLAG_SYNC, too. Then renaming and metadata got added and now we found a situation where we again need the pure initial meaning. We could separate the 3 different sync flags, like we have for locking.

The new solution avoids this.

Good. 👍

Do we have an agreement to get rid of meta:/origvalue and instead only using meta:/internal/* instead?

Yes, origvalue is broken and should not be recommended anymore. BUT only using meta:/internal/* is not a replacement. We need a way to let plugins know, when a key's value has changed. For that we need the additional flag.

Also there is this example in the toml plugin README. It uses/abuses origvalue to let users set key to a non-decimal value. The new solution doesn't really have a mechanism for that. You would have to use a kdb set with a decimal value. However, this probably more of a tools issue.

I mark this issue stale as it did not have any activity for one year. I'll close it in two weeks if no further activity occurs. If you want it to be alive again, ping the issue by writing a message here or create a new issue with the remainder of this issue.
Thank you for your contributions 💖

meta:/internal/* would be a solution if the type plugin is the only plugin that rewrites values. Then the one way how the type plugin saves the original value would be the only relevant place.

I agree that tooling might be interested in what the original value was. So maybe we should not make it internal and use meta:/value/original to store the original value? But still, only the type plugin would be responsible, otherwise there would be a mess like it is now.

We should even make a check in the contract that only one plugin writes a certain meta-value (it is okay if many read it).

So maybe we should not make it internal and use meta:/value/original to store the original value? But still, only the type plugin would be responsible, otherwise there would be a mess like it is now.

Yes, we definitely need a public "contract" to define how this kind of value conversion should be done. Ideally there would be library functions that handle everything except the actual conversion. But I'm not sure how feasible that is.

Only type doing any conversion is a definite no-go, because there are things like color and hexnumber that do valuable conversions. We cannot possible integrate all of this into type. Also there are plugins like toml that do direct conversion from the storage file and only use type for additional checking.

The basic problem here is just that some "internal" values have multiple "external" representations and we need to remember which one was used. So we broadly need two things:

1. When the first conversion happens, we need to remember the original value.
2. We need a way to check, if a key value changed between kdbGet and kdbSet.

How this is best achieved, I don't know. Unless we find a simple solution, fixing this issue should probably be part of #4424, since it is kind of related to the whole specification system.

We should even make a check in the contract that only one plugin writes a certain meta-value (it is okay if many read it).

How would you check/enforce that?

I mark this stale as it did not have any activity for one year. I'll close it in two weeks if no further activity occurs. If you want it to be alive again, ping by writing a message here or create a new issue with the remainder of this issue.
Thank you for your contributions 💖

I closed this now because it has been inactive for more than one year. If I closed it by mistake, please do not hesitate to reopen it or create a new issue with the remainder of this issue.
Thank you for your contributions 💖