-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RIA-specific URL handlers #105
Comments
With regard to #103, I would opt for dropping it. An explanation for this verdict is provided in this comment: #103 (comment) |
W.r.t to #102, I would currently opt for an |
Commented on datalad/datalad-next#454 here: datalad/datalad-next#454 (comment). My current point of view is that we should not support a force-mode, but let the user take action, if |
With #596 close to the finish line and an improved understanding of the usage scenarios, I would like to describe the current state. The Implementing an Up until now, HTTP was only used to read from an annex remote, i.e. the HTTP-handler would only implement |
I opened PR Atomic UrlOperations.upload for ssh- and file-URLs in datalad-next which addresses the atomicity-requirement for |
A number of issues have been determined that prevent the direct use of the
UrlOperations
provided by datalad-next:ensure_writeable(path.parent)
#103UrlOperations.delete|upload()
datalad-next#454One way to side-step this issue is to have a RIA-specific collection of handlers. We could use the standard URL handler selection mechanism (via config) to specifically choose these (bases on the standard
ria+
prefix).Each of these to-be-implemented handlers could subclass the analog from datalad-next, and amend the implementation with a suitable API and functionality.
The downside of such a move would be that any protocol would need a dedicated ria-variant to become compatible.
The text was updated successfully, but these errors were encountered: