Will the flux of futures versions of ODK Collect still be backwards compatible with old techno?

Support
1

1. What is the problem? Be very detailed.

Actually I don't have a problem, it is to anticipate.
I have custom php scripts which communicate with ODK Collect.

In ODK Collect v1.30.1, in the configuration screen of the server, i can read this information message

"Custom server paths
Will be removed in a future release. Please use / formList and / submission on your server."

Does
https://mydomain/passerelle will not work any more ?
with existing scripts like
https://mydomain/passerelle/formList
https://mydomain/passerelle/submission

Will I have the obligation to move my communication scripts at the root of the domain ?
like
https://mydomain/formList
https://mydomain/submission

I try odk central in local,
and when i configure ODK Collect with a QR Code generate by ODK Centrale for a form campagne, i see complicate authentification access in ODK Collect side like
URL server : https://mydomain/v1/key/I$O66........o$X/projects/34
without any user and password needed

Does the old authentification by user/password will disappear in the futur of ODK Collect ?
Will the compatibility of the exchange flow between ODK Collect and the old ODK Aggregate project will be impossible in a near future ? (this question because finally my scripts are modeled on this process.)

2. What app or server are you using and on what device and operating system? Include version numbers.

ODK Collect v1.30.1
php script server side

3. What you have you tried to fix the problem?

4. What steps can we take to reproduce the problem?

5. Anything else we should know or have? If you have a test form or screenshots or logs, attach below.

For now the communication was very stable since I used it (2017), i have made any change.
I hope for me that future versions of ODK Collect will be still compatibles with ODK Aggregate flow, like my scripts are based on them.
It is for anticipate problem on my work.

Thanks :smile:

2

Here's my unqualified take:
Central replaces Aggregate, and it has a very nice API with an excellent documentation.
It's probably a good idea to plan your migration from Aggregate to Central.

Central still uses OpenRosa like Aggregate, so the functionality of its OR API should (I think) be the same. If that's the case, it shouldn't be too hard to adjust your scripts to the new API endpoints.

Alternatively, you can use Central's new API endpoints (submission export, OData, restful) to extract data in a much more usable format. See the interactive API docs for working examples in many languages.

Third party API wrappers like ruODK (if R is your jam) do some more parsing and formatting for you, see the worked examples in the vignettes in the ruODK docs.

3

Thank you for taking the time to answer Florian.

As you say, the XML message does not change, I wondering on the client server connection / exchange aspect in the future.
It is true that the question aimed the team which drives the project.

I was asking if in the future the ODK client would keep its connection possible with a simple user / password which makes accessibility of understanding much easier to develop a gateway to another tool.
RFC 2617 (HTTP Authentication: Basic and Digest Access Authentication)
https://docs.getodk.org/openrosa-authentication/
Because I noticed security became more complex in ODK Central with the little testing I carried out.
For the moment, the interaction between the different evolutions of the project is stable, old and recent communicates. It's truly pleasent.

Indeed the package ODK client and Centrale is a great tool when starting from scratch for a data collection campaign.

But my view is another way to benefit from the work done by ODK without having to use all the suite ODK.
One my way i don't have to manage a central (or aggregate) server, I already have an apache service and php web application,
so i don't want to have a nodejs service (backend frontend)..., and learn a new api (centrale) to transfert data to my database modele.
I directly process the flow of data arriving from the odk client, reading xml reponses and then storing reponses in my database.

This is an interesting approach to simply hook a collect smartphone application to your existing application, keeping your programming language, in my case Php .

I think that extends the potential use of ODK, because not everyone is concerned with the whole kit.

I don't have the impression that many people have tried the experience like me,
to interface the client to their database, I found very few examples and I don't know if they are still in used.
When you have an existing php web appli, it is also very efficient and easy to implement.

4

You use /formList and /submission so you will not be affected. You can specify anything you want as the server URL and those endpoints will be added to fetch the form list and make submissions.

The endpoint names formList and submission were not initially specified and those could be given arbitrary names that would be specified as Collect settings. That is the functionality that is being removed because it's confusing for users to see in the settings, it's only very narrowly used, it's error-prone, and the benefits to server creators are low.

For now we have no plans of removing support for basic and digest auth. We will hopefully introduce a standard API for token-based auth which is more efficient and secure in the near future.

If you do choose to stay on your custom implementation, make sure that you read every community announcement and keep an eye on the development category. We try to maintain compatibility but we sometimes are forced to remove functionality to comply with Android API requirements. Additionally, when we see that features which are a maintenance burden or otherwise cause confusion are very narrowly used, we may remove them.