Private addon storage

[funkydude]

This is a feature request to allow addons to define saved variables that are not assigned global variables by default.

Addons can activate this by defining the following in the toc file: ## PrivateSavedVariables: true

This would send a table to each Lua file in the addon, similar to the addon scope table.

local addonName, addonTable, addonSettings = ...

addonSettings.colors = {}
addonSettings.name = true
addonSettings.global = {}

_G.myAddonSettings = addonSettings.global

This would not replace the current system, it would run alongside it. The addonSettings table can be stored in the current saved variables file, or a separate one.

This would also have the benefit of allowing addons to use their storage immediately, instead of waiting for their respective ADDON_LOADED event to read them.

[Meorawr]

I'll nit up-front and suggest it should be ## PrivateSavedVariables: 1 like all the other boolean-style TOC flags.

From the description it sounds like turning this feature on would mean that the entire contents of addonSettings in your example would be saved to an (undefined) saved variables file - so per your example all of colors, name, and global should be persisted.

There's a few issues that come to mind as-described however;

• The proposal doesn't accomodate the existence of the three storage types for saved variables all in use today - account-wide, character-specific, and (for Blizzard) machine-specific.
• The proposal says it runs "alongside" the current SV system but doesn't elaborate what this means - do I have to lose all my data to turn this feature on?
• The proposal ties the timing of the data being loaded into the private scoping, which adds potential questions around cases where both old and new systems are in use simultaneously.

I don't feel as though the character and machine-specific use cases can be ignored. Blizzard would benefit greatly from a UI security standpoint if private scoping were unilaterally in-use across all their addons, and there's no shortage of addon code today that has valid use cases for character-specific storage.

With respect to mixed use cases and migrating existing addons to use this feature, if an addon that today has both SavedVariables and SavedVariablesPerCharacter defined and then tomorrow turns on PrivateSavedVariables, what's the expected outcome?

• Will the global variables named in those SV directives be loaded, or are the old files completely ignored and all data effectively lost?
• Will the global variables named in those SV directives be loaded first alongside the private storage, or will addons have to deal with a mixed case of private-scoped data being loaded first but "legacy" SVs being loaded last?

I think this one little directive is trying to do a bit too much on its own and needs slightly splitting up.

• Turning on PrivateSavedVariables should supply a "private table" to all scripts in an addon, as per your suggestion.
• When addon data is loaded, the contents of this table should be populated with the contents of the saved variables files that are in-use today.
• When addon data is written out, the keys defined in the SavedVariables, SavedVariablesPerCharacter, and SavedVariablesPerMachine directives are then read from the private table and are then persisted to disk in the appropriate files.
• Effectively, the only functional difference is what table all the variables are stored in at runtime - if this feature is disabled, it's _G. If it's enabled, it's the private table. All other logic regarding the reading and writing of the data itself remains identical to how it functions today.
• The timing of the data being loaded is a completely orthogonal concept that should be handled by a separate TOC directive like SavedVariablesLoadFirst: 1 (see #414).
  • This means addons which don't feel as though they benefit from private-scoped storage can still opt-in to having their data loaded early.

In practice, this would look as follows:

## PrivateSavedVariables: 1
## SavedVariables: Foo
## SavedVariablesPerCharacter: Bar
## SavedVariablesLoadFirst: 1

local _, _, SavedVariables = ...

SavedVariables.Foo = 1 -- This will be stored in account-wide saved variables file for the addon.
SavedVariables.Bar = 2 -- This will be stored in character-specific saved variables file for the addon.
SavedVariables.Potato = 3  -- This isn't defined in the TOC, and so shouldn't be persisted at all.