Consider Refactoring tfsdk Config/Plan/State Logic into internal Package(s)

[bflad]

Module version

v0.8.0

Use-cases

While working through some of the framework server refactoring as part of #215, it was necessary to extract some of the tfsdk.Config, tfsdk.Plan, and tfsdk.State unexported methods into temporary functions within the internal/fwserver package so they did not become part of the public tfsdk APIs. For example, ConfigGetAttributeValue(). This highlighted that a larger portion of the "schema data" handling would benefit as being in internal packages and colocated again, rather than splitting the logic across packages, while still exporting provider developer functionality only as necessary in tfsdk or some other "public" package.

Proposal

To be written up, but a current thought is that there should be an internal/schemadata or similar package which contains the full framework schema-based data handling, while tfsdk or another package merely exposes anything that should be in the public API. Ideally, there would be a single implementation for readable and writable data that is shared across the Config/Plan/State implementations.

References

• #215