OpenRefine
Support the reconciliation protocol version 1.0-draft
Over at the reconciliation community group, we have been making improvements to the reconciliation protocol. The goal is to make it easier to implement reconciliation services and clients and add missing features. While many of such improvements have been done in a non-breaking way from 0.1 to 0.2, the version 1.0 that we are currently working towards includes a range of incompatible changes (such as the way reconciliation queries are submitted to a service). Therefore, services which currently follow the 1.0-draft specification are currently incompatible with OpenRefine.
Proposed solution
Implement support for the 1.0-draft protocol in OpenRefine, keeping compatibility with version 0.1 / 0.2.
One approach to doing so would be to start by proxying all reconciliation calls from OpenRefine's frontend through its backend (#7185). Once that is done, we could add the logic of supporting the different protocol versions in the backend, meaning that the frontend wouldn't have to know what version is being used. This compatibility layer in the backend could be a reusable Java library (for instance https://github.com/wetneb/ReconToolkit which I started with this in mind).
Alternatives considered
There are surely other ways to introduce such a support.
Additional context
An overview of known implementations of the protocol and the versions they support can be found at:
- https://reconciliation-api.github.io/testbench/
- https://reconciliation-api.github.io/census/
It's worth noting that, as its name suggests, version 1.0-draft is still being worked on and is therefore a moving target. On one hand it can be worth waiting for it to be stable before implementing it, on the other hand implementing it early is a good way of identifying issues in the specifications and addressing them before the protocol is stable.
The new protocol would be helpful to solve the following issues: #6234, #6053, #6044, #4715, #3139, #2332, #2075
Agree, and I'd rather implement the 1.0-draft and start shipping SNAPSHOT versions of OpenRefine at a minimum to get user feedback quickly.
I'm very much in favor of this the 1.0-draft is so much easier to develop against but implementers hare held back by the lack of support in OpenRefine.
An alternative might be to push for a 0.3 version? The downside is of-course future breaking changes and maintainability but that might be better than having a moving target for an unknown amount of time?
Related discussion about negotiating API versions over at reconciliation-api/specs#78.