I think that the more we can avoid this the better but I also recognize that it's going to be tough given the different mental models that the different clients have. Ideally we can at least document official keys and have a process for proposing and approving additions. Naturally, nothing would stop "rogue" clients and servers for going outside of that list.
I see what you're getting at but I'm not really sure that it would be a good thing for the clients to get only the subset that they care about. There's benefit to having a smaller response payload but the cost is having a request payload. That payload will need to include all of the settings that the client supports even though the server might only need to specify a couple of settings.
What I'm more concerned about is letting somebody know that settings that were specified were ignored by the client. That could even be between versions of the same client. Let's say ClientX v1.2 has awesomeSetting but ClientX v1.1 does not. I think we want someone to be able to tell that awesomeSetting was not applied. Having the client only request the settings it cares about doesn't help with that.
There's a lot going on here. I want to be clear that I'm still forming mine as well and everything is up for discussion.
Yes, exactly. A general setting provides a setting value. An admin setting determines the visibility of its setting/feature. For example, you can set auto-send to true in general settings and then set the corresponding admin setting to false. That means submissions are autosent and the setting is not visible to a user without the admin password. On the other hand, if the admin auto-send setting is true, any user can override that setting.
I think it definitely makes sense to include admin settings in QR code configuration since that generally happens once. You could imagine giving e.g. supervisors the admin password and letting them modify some settings in the field if needed.
User override is much harder to reason about and may not make sense in the case of remote settings management. As you say in your last point, this spec should probably make a statement about whether they're allowed.
I'm guessing that for Enketo it makes perfect sense to just not accept manual settings changes for the current form if remote settings are received. It's a little tricker for Collect because the server/username/password must be reconfigurable somehow or the app ends up forever 'locked' to a specific server unless that server provides the URI and credentials settings for a new server. At the same time, we don't want just any enumerator to be able to reset server and credential settings. Here are two ideas:
- Don't include server and credentials in these remote-configurable settings. I don't think they would be useful for Enketo anyway. For Collect, they need to be provided outside of a settings API initially anyway to boostrap. Only include a single admin setting: admin password. It only governs whether server settings can be changed. If there's no admin password, server settings are always available to change (basically logout/login). If there's an admin password, the password is required to change server settings. No other setting is available to change unless the server is changed to one that doesn't provide a remote configuration.
- Include server info and credentials. Same thing with the admin password being the only admin setting and governing access to the server and credentials settings. The advantage here is that it makes changing servers or projects much easier. Without those settings in the configuration, switching to new server information e.g. at the start of a new project would require physical access to devices.
I agree with the sentiment. As you say, it's hard to reason about. For example, whether or not drafts may be edited can make a big difference in the meaning of the data collected. I'll try to make a shortlist of keys that seem to change the meaning of data collected in that way when I revisit Proposal: publish a settings key/value standard.