-
Notifications
You must be signed in to change notification settings - Fork 436
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Need to clarify how to handle multiple data sets over the same channel in DPL #939
Comments
Should you use subspecification for that? |
Not necessarily. One can think of sending multiple parts with the same We can make a policy requiring unique If we agree on that we can label this issue as bug and make a patch soon to check for duplicate |
I think actually that the fact we allow it right now is a bug. As you point out it would become impossible for the receiving side to decide how many messages to wait for, so I do think that "multiple parts" should really mean "multiple subspecifications" (or maybe a newly introduced field, if you see that for detector specific stuff?). |
some first ideas on that topic
User story: a processor defines one channel. In one single invocation of the processing callback it want's to send multiple data sets of identical
OutputSpec
over the same channel, e.g. via multiple calls tosnapshot
oradopt
. The receiver might expect theses messages to arrive in the sameInputRecord
of one single invocation of its processing function.There are different use cases.
Probably these different use cases need to be clearly expressed in the workflow definition. And definitely something we have to do clarify to avoid confusion.
The text was updated successfully, but these errors were encountered: