1. What is the general goal of the feature?
Simplify the server configuration experience. Currently, the three available server types are "ODK Aggregate", "Google Drive, Google Sheets", and "Other". "ODK Aggregate" is confusing for folks who use ODK Central or any third-party server. "Other" is confusing because it's the same as "ODK Aggregate" with the added possibility to specify custom OpenRosa endpoints. The "Other" name suggests this is a whole different kind of server but it's really not.
We intend to remove custom server paths in an upcoming Collect versions. Analytics show that this is rarely used. It's unclear why an alternate server would implement the formList and submission endpoints but give them different names. If you use custom server paths, please let us know why.
2. What are some example use cases for this feature?
Folks who don't configure through a QR code need to go through this settings screen. Simplifying it should help the onboarding process.
Deprecating settings that are not commonly used will simplify the settings key/value standard that we would like to publish for all ODK-compatible tools to use.
3. What can you contribute to making this feature a reality?
Project management, development.
Please share if you have any feedback! This was briefly discussed during the latest @TAB call but we didn't have much time for discussion.
OK, you want to know why folks use custom server paths. I use them because my whole server is custom, with the app data-collection only one of many functions which the server fulfils - so I'd rather not have my directory structure dictated by the app.
I'm also not sure that I follow your logic for removing custom server paths. Given that the default configuration is for Aggregate, and QR code configuration is possible, there is both default and simple configuration for how most people use the app. The custom paths option doesn't even appear unless the user selects "Other" for the server type - so I can't see how removing custom paths simplifies the process for an Aggregate or Google user.
I use a (very slightly) customised fork of the app, in conjunction with the custom server - my functionality requirements can't be met by a QR code configuration. So I can always bake in my own custom paths if I want to - but being able to edit the paths (for example to switch between test and live servers) without rebuilding the app is very handy.
If the intention is to discourage folks from developing custom servers for Collect, or from forking the app for separate projects, then I can see the point - but why would you want to discourage this? If you don't want to discourage use of custom servers, I think that's an argument for leaving custom paths in.
+1. Since these endpoints are technically part of the OpenRosa API definition, at best I'd say you might want to support a custom prefix for them - which can just be handled by the URL path - but I dont think there's a completing reason to support quasi-OpenRosa compliant servers that choose to rename them to something completely non-standard [sic].
That makes sense! Could you please share what endpoint names you have chosen? That might give us some insights into cases where name might be more important. As @Xiphware has mentioned, I would typically expect some kind of route prefix (containing project, user that owns the form list, etc) but that would be included in the server URL. It also seems to me that using the default endpoint names and adding an alias at the server level would be simpler and easier to maintain than forcing clients to configure those names.
Could you please describe why you use different paths for test and live servers? What are those different paths?
That is true, but there are many folks who use all kinds of third-party servers. Those typically use the standard URL paths but some users still select "Other" and then are not sure what to do for the paths.
This is probably not directly related to this conversation so it's not necessary but I'd be interested in hearing more about those requirements in case they may be addressed by other ideas we've been considering.
Not at all. In fact one of the motivations is to make things easier for folks who use third-party servers.
