You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now that we have shell, we could use it to implement handlers for protocols that enable extending and outsourcing functionality via 3rd-party utilities that implement this protocol rather than implementing (Python-based) helpers or subclasses -- exactly what git-annex does for special remotes and backends.
For each such use case we would define a set of operations, and expose them via a protocol. This pattern could be widely applicable. We already archived at this concept (albeit with Python-based implementations) for
URLOperations
ArchiveOperations
Other use cases are:
siblings: we can do create, but nothing else. We need/could have:
git-annex special remote driver: git-annex is the only software that implements the git-annex custom remote protocol. Having a second implementation would not be a bad thing. Some special remotes might even be usable for non-git-annex functionality...
The text was updated successfully, but these errors were encountered:
Capturing an idea that came up in a different context: datalad/datasalad#7 (comment)
Now that we have
shell
, we could use it to implement handlers for protocols that enable extending and outsourcing functionality via 3rd-party utilities that implement this protocol rather than implementing (Python-based) helpers or subclasses -- exactly what git-annex does for special remotes and backends.For each such use case we would define a set of operations, and expose them via a protocol. This pattern could be widely applicable. We already archived at this concept (albeit with Python-based implementations) for
URLOperations
ArchiveOperations
Other use cases are:
remove-sibling-*
datalad#5946The text was updated successfully, but these errors were encountered: