Prefs Storage Mapping Strategy (Import / Export) #9
Description
Proposal
While PrefsStorage implementations define their own canonical way to read and write all atomic value types to their storage, there appears to be the need for an additional paradigm to define how data can be imported and exported from different file formats (which is not all that dissimilar from storage backends themselves).
For example, a DictionaryPrefsStorage instance:
- can import/export data to/from a plist (Property List) file fairly seamlessly, as the value types match essentially 1:1 between the two formats; very little logic, casting, or type conversion is necessary to interchange these two formats
- however, import/export to/from JSON format has some value types that map 1:1 but some that do not
Possible Solution
One (or both) of the following abstractions could be introduced to allow defining how value types are translated/mapped, when necessary:
Two new protocols could be introduced: PrefsStorageImportStrategy and PrefsStorageExportStrategy.
These protocols would require methods to translate/map one format's value types to common native value types storable in a PrefsStorage instance. Default implementations can be provided for value types such that only values that require specialized treatment could be implemented/overridden by the concrete strategy implementation.
In practical terms there would exist a pair of default concrete strategies for PList included in the library. (It would still be possible for a user to implement their own mapping strategy for PList if they wish.)
However, strategies for JSON import/export are ambiguous, since not all value types exist in JSON (there is no native data or date encoding, and JSON includes a null value type that PrefsStorage does not support as an atomic value type). A default pair of concrete strategies could be provided using sensible default translations/mappings for these types, but users will likely want to implement their own to handle these types as they see fit.
Considerations
As presented, this proposed solution would enable novel storage encodings to be converted to and from atomic PrefsStorageValue types, but not convert directly between two novel storage encodings. Which means that there is a potential for data types to change or values to be lossily converted at certain stages. However, there is value and merit in providing the functionality still.
Additionally, since some value types cannot be inferred from the storage format, a key-based translation mechanism may be required (akin to PrefsStorage itself, defining key names and their static value types). For example, date and data value types have no native encoding in JSON, which means the user must 1. decide on an encoding format for them and 2. know which keys are of these data types, as this cannot be inferred automatically.
Also, when exporting, only actual storage contents will be exported. Default values for any preferences that have not been accessed or mutated will not yet exist in the storage (as default values are not implicitly written to storage), and will therefore not be exported.