Change Details

This is based on my understanding of how it currently works, and this comment by @moranegg: https://forge.softwareheritage.org/D637#inline-3321 I introduced the following changes: * introduced the concept of "gatherer" as a metadata provider, as a catch-all for everything that does not fit in the other types, eg. if we decide on implementing this: https://forge.softwareheritage.org/T833#31999 We can discard it afterward if we don't need it. * Dropped the concept of 'tool'. As far as I understand, they are an intermediary between the provider and the SWH archive. IMO they only complicate stuff if we plan on extracting metadata from providers without any change. * Changed the described endpoints to drop the concept of "provider id" (you know I don't like extrinsic identifiers by now :) ) * Changed the described endpoints to give consistent names to the parameters.

This is based on my understanding of how it currently works, and this comment by @moranegg: https://forge.softwareheritage.org/D637#inline-3321 I introduced the following changes: * introduced the concept of "gatherer" as a metadata provider, as a catch-all for everything that does not fit in the other types, eg. if we decide on implementing this: https://forge.softwareheritage.org/T833#31999 We can discard it afterward if we don't need it. * Dropped the concept of 'tool'. As far as I understand, they are an intermediary between the provider and the SWH archive. IMO they only complicate stuff if we plan on extracting metadata from providers without any change. * Changed the described endpoints to drop the concept of "provider id" (you know I don't like extrinsic identifiers by now :) ) * Changed the described endpoints to give consistent names to the parameters. Resolves T1737.

This is based on my understanding of how it currently works, and this comment by @moranegg: https://forge.softwareheritage.org/D637#inline-3321 I introduced the following changes: * introduced the concept of "gatherer" as a metadata provider, as a catch-all for everything that does not fit in the other types, eg. if we decide on implementing this: https://forge.softwareheritage.org/T833#31999 We can discard it afterward if we don't need it. * Dropped the concept of 'tool'. As far as I understand, they are an intermediary between the provider and the SWH archive. IMO they only complicate stuff if we plan on extracting metadata from providers without any change. * Changed the described endpoints to drop the concept of "provider id" (you know I don't like extrinsic identifiers by now :) ) * Changed the described endpoints to give consistent names to the parameters. Resolves T1737.