Open mih opened 6 months ago
In a first implementation https://github.com/christian-monch/datalad-compute, a POC that will turn in an MVP, the first option for key-based information storage was chosen, i.e. "URL-encoded parameter list via an added "availability URL", as done in https://github.com/matrss/datalad-getexec"
From a user POV, we want to present a compute-on-demand like a download-on-demand, and wrap everything into a git-annex special remote. This means that we are bound to that protocol, which translates to an API that has the
request-this-key
as the main entrypoint.So at the start of an operation, we only know which key is requested. Therefore the instruction on computing a key needs to be (discoverably) recording in association with a particular key.
Three established patterns for storing key-based information are known:
GET/SETSTATE
in the special remote protocolChallenges:
request-one-key-compute-one-key
, but one computation can produce more than one keyGET/SETSTATE
is not directly exposed to a user-facing APICandidate solutions:
cwl:tool
could be a well-defined, JSON-serializable format that would fit the requirements, and could be stored via git-annex remote key state or metadata.