[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [dataspace-protocol-base-dev] Question: About extending the control plane to supply data filtering conditions
|
Dear José,
If I may add to Jim’s answer.
The DSP TransferRequestMessage (control plane) is not the data request actually initiating a data transmission (data plane). It is rather to be seen as a “Hey, let’s come back to our Agreement. I want to start sharing/consuming data. Is everything set up? Here is what I need/require”. Other DSP transfer messages may indicate a suspension, problem, or ACK about the end of a data transmission (on the data plane).
Following this, the transfer format specifics are
- indicated as format of the distribution in the catalog,
- part of the dataAddress in the TransferRequestMessage or TransferStartMessage (there you have the requested extensibility, see EndpointProperty [1]),
- and part of the data request on the data plane (not in scope of DSP, e.g., filter properties).
I would add a few things here regarding the use of the data address.
The data address is not designed to tunnel wire format operations from the consumer to the provider for pull operations. The description of the Transfer Request Message describes this: "The `dataAddress` property MUST only be provided if the `format` requires a push transfer.” If the consumer includes wire protocol options in the data address, it will likely break many implementations that do not require them to initiate pull transfers on the provider. It’s also not an efficient design, as it requires the data plane to maintain additional state (filter params). The purpose of the Data Address is to pass endpoint information (address, auth) between participants.
For push transfers, one could (ab)use the data address to tunnel filtering information. However, a data address is intended to be an endpoint reference, not a data selector. It’s more efficient to solve this in other ways:
- On the provider side, model a dataset to filter data implicitly, i.e., have a dataset for each filter combination.
- If this is not practical or desirable, handle the issue at the data plane layer. For example, if a message streaming protocol is used, have the client expose a topic/channel that filters messages (push) or redesign the protocol using streaming pull where the client subscribes to specific message types at the provider. For REST-based protocols, allow filter params.
Jim
