Overview of technical implementation aims

[adswa]

[Taken from RFD]

• Switch previous custom HTTP IO implementations to datalad-next's URLOperations.
• More consistent and comprehensible user messaging
• Implement progress reporting
• Robustify, decomplexify, and thoroughly document reconfiguration logic for remote access URLs. Currently there are url and push-url parameters, but insufficiently documented. It seems possible and advisable to migrate such configurations over to a (set of) "sameas" special remotes, one for each access mode -- rather than switching existing configurations. If auto-detection of connection/location is done, it should likely be done with yet another "sameas" remote in "private" mode, i.e. not committed in the git-annex branch (if that is possible). See Switch/abandon ORA abstraction paradigm #30
• Replace previous custom implementations for SSH-based remote operation (their main feature is download via a persistent remote shell to avoid offset cost on systems like JURECA where it takes 600ms to start a shell (even with a pre-authenticated connection)). Potentially switch to datalad-next's URLOperations
• Honor server-side configurations and clean-up requirements (add shared access support, leave no cruft behind)

[adswa]

Overview of issues: https://github.com/datalad/datalad/issues?q=is%3Aissue+is%3Aopen+label%3ARIA%2FORA

[loj]

Adding this KBI issue, which includes some user questions/desired functionality asked about in the DataLad matrix channel.