{"action":"created","issue":{"url":"https://api.github.com/repos/aspnet/Configuration/issues/549","repository_url":"https://api.github.com/repos/aspnet/Configuration","labels_url":"https://api.github.com/repos/aspnet/Configuration/issues/549/labels{/name}","comments_url":"https://api.github.com/repos/aspnet/Configuration/issues/549/comments","events_url":"https://api.github.com/repos/aspnet/Configuration/issues/549/events","html_url":"https://github.com/aspnet/Configuration/issues/549","id":188383414,"number":549,"title":"User settings API","user":{"login":"divega","id":1253414,"avatar_url":"https://avatars.githubusercontent.com/u/1253414?v=3","gravatar_id":"","url":"https://api.github.com/users/divega","html_url":"https://github.com/divega","followers_url":"https://api.github.com/users/divega/followers","following_url":"https://api.github.com/users/divega/following{/other_user}","gists_url":"https://api.github.com/users/divega/gists{/gist_id}","starred_url":"https://api.github.com/users/divega/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/divega/subscriptions","organizations_url":"https://api.github.com/users/divega/orgs","repos_url":"https://api.github.com/users/divega/repos","events_url":"https://api.github.com/users/divega/events{/privacy}","received_events_url":"https://api.github.com/users/divega/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":3,"created_at":"2016-11-09T23:52:08Z","updated_at":"2016-12-01T20:27:29Z","closed_at":null,"body":"Note: I am creating this high level issue with the main purpose of starting a discussion about a set of requirements that I hear relatively often about but that I believe Microsoft.Extensions.Configuration wasn't actually designed to satisfy. This could either lead us to: \r\n1. Pursue a new direction for Configuration\r\n2. Build a new separate feature  \r\n3. Decide we really don't want or need to do anything in this space. \r\n\r\n### Background\r\nApplication configuration (i.e. what Microsoft.Extensions.Configuration currently does) and “user settings” (still trying to find a better name for it) appear (at least to me) to be two distinct features with different requirements. \r\n\r\n|Aspect |Application configuration |User settings|\r\n|-|-|-|\r\n|Scope |Very narrow; only things that affect the whole application (or host) on startup. Possibly this makes it ok for providers to eagerly load all configuration data into memory |Any configuration that is pertinent to a given application domain on a per user basis. Likely more appropriate to load only the required data, on demand|\r\n|Sources |Mostly command line, environment and a small number of files on disk |Shared and remote resources such as databases|\r\n|Sync-vs. async |All sync (mainly runs in constructor of `Startup`) |Mostly async (mainly runs in requests)|\r\n|Can depend on DI? |No, too low in the stack (although we layered Options on top)|Definitively|\r\n|Persistence |Not too important: it is reasonable to make changes out of band (e.g. by editing a file) as they happen infrequently and are only initiated by the application’s admin or developer |Very important as changes happen frequently as part of the application logic and are initiated by application users|\r\n\r\n**1.  Extend Configuration?**\r\nAt first glance, it seems that there could be an opportunity to reuse the same interfaces representing configuration sources, providers, builders and `IConfiguration` nodes, only with new capabilities, such as async access and persistence, combined with new provider implementations that are lazier and more efficient. There is an obvious impact to the current feature in the form breaking changes and/or proliferation of optional extension interfaces containing the new functionality. Microsoft.Extensions.Configuration could become more complicated than it is today. There is also the question on how Options would work with async: It seems hard as Options in common usage do work in non-async paths, such startup and class constructors, but we could promote using async lambdas and defer obtaining values until we are in an async methods. \r\n**2. Build a new feature?**\r\nI believe one of the reasons reusing the same interfaces may feel compelling at first glance is that in simple single-user applications the requirements of application settings and user settings may be undistinguishable: think turning off the music and FX in your favorite game on the phone. Is that an application setting or a user setting? One a multi-user Web application, it should be easier to tell them apart.\r\nSo, if we don't use the existing interfaces, maybe we can still reuse some of the same patterns from Configurations and Options? (see @HaoK's comment below for some snippets of how this could look like)\r\n**3. Do nothing?** \r\nThe two alternatives above assume customers wish to communicate with the storage of user settings through a set of common abstract interfaces. But how are user settings different form the domain-specific data many applications just store in databases through their database API of choice today? What value would the abstractions actually bring to the table? What limitations would they impose that would prevent users from leveraging the richer capabilities of the underlying stores?\r\n"},"comment":{"url":"https://api.github.com/repos/aspnet/Configuration/issues/comments/264285178","html_url":"https://github.com/aspnet/Configuration/issues/549#issuecomment-264285178","issue_url":"https://api.github.com/repos/aspnet/Configuration/issues/549","id":264285178,"user":{"login":"divega","id":1253414,"avatar_url":"https://avatars.githubusercontent.com/u/1253414?v=3","gravatar_id":"","url":"https://api.github.com/users/divega","html_url":"https://github.com/divega","followers_url":"https://api.github.com/users/divega/followers","following_url":"https://api.github.com/users/divega/following{/other_user}","gists_url":"https://api.github.com/users/divega/gists{/gist_id}","starred_url":"https://api.github.com/users/divega/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/divega/subscriptions","organizations_url":"https://api.github.com/users/divega/orgs","repos_url":"https://api.github.com/users/divega/repos","events_url":"https://api.github.com/users/divega/events{/privacy}","received_events_url":"https://api.github.com/users/divega/received_events","type":"User","site_admin":false},"created_at":"2016-12-01T20:27:29Z","updated_at":"2016-12-01T20:27:29Z","body":"Updated original post with some more thoughts."}}
{"actor":{"display_login":"divega"}}