Open xamcost opened 4 days ago
Pinging @psotres , @juanrasantana and @telsaleh for their feedback! Compared to step 1 described in Sedimark/marketplace-frontend#5 , there are much more questions to address here. Highlighting them:
This step aims at gathering all information needed by the connector to fetch the data from its source. I guess most of these information will not appear in the offering self-description, but will be stored in the connector, right ?
⚠️ We (marketplace developers) assumed that data sources can only be accessed through HTTP requests! Please tell us if it isn't the case.
Note that many of these parameters could be exposed on the consumer side as well, when requesting a transfer. For instance, the consumer could add a subpath to the request URL, as well as a body, headers and query parameters (potentially overwriting the one set by the provider). Please let us know if this should be the case.
And of course any other feedback you see fit.
Thank you for your feedback @psotres . Ok we will stick to HTTP then. Yet there are two things we would need to know, but most likely @telsaleh , @juanrasantana or INRIA can answer:
Offering
or AssetProvision
corresponding to the request to perform to the HTTP data source endpoint, but maybe we are just missing it ?Thanks in advance!
Hi there! The goal of this issue is to decide what to put in the second step of the offering publication wizard, dealing with the access to the data asset to be published. This step aims at gathering all information needed by the connector to fetch the data from its source. I guess most of these information will not appear in the offering self-description, but will be stored in the connector, right ?
⚠️ We (marketplace developers) assumed that data sources can only be accessed through HTTP requests! Please tell us if it isn't the case.
More precisely, this page should contain:
Note that many of these parameters could be exposed on the consumer side as well, when requesting a transfer. For instance, the consumer could add a subpath to the request URL, as well as a body, headers and query parameters (potentially overwriting the one set by the provider). Please let us know if this should be the case. I suggest to discuss the interface for this in a separate issue.
At date of writing, this step looks like this: