Unified media handling

In #459 I discussed some future steps we could take to further simplify media URL logic. This issue will be used to track those changes. Depending on the size, and coherent overlap of the work described here, I may submit a single PR, or break it into smaller chunks.

Tasks

• Generate media URLs client-side: there’s little remaining barrier to moving media URL parameterization to the client. Besides reducing unnecessary scope of the server’s responsibilities, it will also unblock some of the other changes discussed in the first PR.

• Offline-capable requests for media: currently these requests are handled by replacing src attributes with data-offline-src, with an additional step to look those up and initiate media loading each time a form/instance is loaded, when a form is reset, when repeat instances are added, and so on. This distinction can be eliminated, instead handling those requests in fetch events within the Service Worker. We may also be able to handle caching at that level rather than in IndexedDB, but I’ll likely split that off as a separate work item and defer it for another future follow-up.

• Consistent handling of media URL resolution and requests: there are several different ways URLs are resolved, depending on their type/role in the form: binary defaults, media in labels, external secondary instances, last-saved, instance attachments. I plan to unify these so that there is one consistent way that all media URLs are resolved and requested/fulfilled.

It may be tempting to combine these last two tasks, as a Service Worker is capable of handling both and it would enable even further simplification. Unfortunately, Service Workers cannot run in some browsers’ private/incognito modes. While this is already a restriction of offline-capable mode, it’s not a reasonable limitation for online-only, edit or preview modes. In any case, consistent handling of URL resolution can be shared, and hopefully the offline portion will just be a small wrapper around that specific to the pertinent Service Worker APIs.

[lognaturel]

there is a line about that in the documentation mentioned under each GET endpoint

Oh! “The GET version of this endpoint is only meant to test the Enketo Smart Paper API in the browser. It does not launch new surveys and is therefore not of use for integrating with Enketo.” Now that you mention it I think you and I talked about this a thousand years ago and I’d totally forgotten and also apparently have forgotten how to read. Thank you! In a parallel universe, the decision could have been made to always use GET for requests that implicitly result in a transformed form being cached. We’re not in that world so can’t change it for the public API but seems reasonable to change it for the private API being discussed here.

[MartijnR]

Each endpoint has GET and POST variants with GET providing a subset of what POST does. I can’t think of any reason to have both.

I remember this one! 😃 The GET requests are only for developers to make a little easier to test (there is a line about that in the documentation mentioned under each GET endpoint). I believe I stole that idea from somewhere else. Stripe maybe.