Swift Configuration is an open-source project developed collaboratively with the community. Similar to other projects like Swift OpenAPI Generator, all significant changes require a proposal, regardless of whether they originate from the project's core maintainers or first-time contributors. The process ensures that everyone is held to the same standard, and it helps us gather comprehensive feedback from the community and guide the project's development.
Looks like a great proposal. Overall +1 on going forward with this. A few minor comments:
public protocol FileParsingOptionsProtocol
public protocol FileConfigSnapshotProtocol
I am not a fan of suffixing the protocols with Protocol . Can we drop that? I see that there are more protocols that existed before this proposal but this it stood really out here.
Instead of locking ReloadingFileProvider strictly into an interval polling implementation was there an API consideration to for custom file-did-update events, mainly for file system watchers on each platform? (like if someone made their own wrapper around libfswatch)
It's not locked in, we can add file watching in the future without it being an API break. The interval is the maximum interval between reloads, but we can reload more often or even based on file system events.
What’s the point of a “maximum” interval though if the provider is observing the file system? I agree that this already bakes in the idea of interval reloading.
A filesystem observing provider should not need/have a maximum interval iiuc.
File system events are prone to missed, duplicate or spurious events across platforms. While they can be used to watch for file changes I wouldn't recommend to rely on them. A time-interval based watching is significantly more reliable and works across platforms easily. So even if we were to extend the file providers to listen to file system events I would still advocate for having a secondary time based mechanism in case the events are not delivered.