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
We tried to cover that discussion in the request-specs as well. You can find it under "exact role of the registry". However, I have to admit we went over that kind of quick and did not formulate it as thoroughly as the first parts. I will try to make that a bit clearer and prepare a pull request.
To summarize quickly: The idea is that we could have a central registry, but that the spec so far is agnostic to that. The reason being: If some additional software component in your client sends the same query to multiple endpoints (e.g. for available types at the endpoints), this would be in a way a virtual registry: just a point where information of multiple endpoints is collected and relayed. "Virtual" because there is no extra host/service that makes up that registry but it is an additional software step. If we do the specification of that "registry interface" right, there is nearly no difference whether that registry is inside the client software, on a dedicated central host, or even multiple registries are hosted somewhere, e.g. if you need one specifically internally in your own institution.
We tried to cover that discussion in the request-specs as well. You can find it under "exact role of the registry". However, I have to admit we went over that kind of quick and did not formulate it as thoroughly as the first parts. I will try to make that a bit clearer and prepare a pull request.
To summarize quickly: The idea is that we could have a central registry, but that the spec so far is agnostic to that. The reason being: If some additional software component in your client sends the same query to multiple endpoints (e.g. for available types at the endpoints), this would be in a way a virtual registry: just a point where information of multiple endpoints is collected and relayed. "Virtual" because there is no extra host/service that makes up that registry but it is an additional software step. If we do the specification of that "registry interface" right, there is nearly no difference whether that registry is inside the client software, on a dedicated central host, or even multiple registries are hosted somewhere, e.g. if you need one specifically internally in your own institution.
Originally posted by @s4b7r in MADICES/MADICES-2024#10 (reply in thread)
The text was updated successfully, but these errors were encountered: