Hi Chris,
but this would only make sense for CYCLIC subscriptions. Whenever a
CHANGE_OF_STATE or EVENT subscription is used, there is no read request
at all, even not a "virtual" one.
If we want to somehow correlate subscription events to what was
requested, I think we should not use getRequest() to do it, but use some
sort of a handle instead (PlcSubscriptionHandle?) or allow the client to
associate a "passback" object with the subscription, which is, well,
passed back to the client along with the subscription event data.
Andrey
On 10/08/2018 05:33 PM, Christofer Dutz wrote:
Hi Andrey,
well usually the Response references the Request ... for the PlcSubscriptionEvent this is
nothing different than repeatedly receiving multiple PlcReadResponses for one Request ...
sort of like creating a PlcReadRequest and calling "execute()" repeatedly on it
without re-creating the request.
I haven't implemented any driver using this interface, but I would assume that
it should reference the PlcSubscriptionRequest as that is where we can see what
was requested.
But I'm open for other interpretations.
Chris
Am 08.10.18, 13:03 schrieb "Andrey Skorikov" <[email protected]>:
Hello all,
the interface PlcSubscriptionEvent extends PlcReadResponse, but I am not
sure whether that is correct: every response has a corresponding
request, which is obtained by calling getRequest() on the response.
However, what request shall be returned if getRequest() is called on
PlcSubscriptionEvent? In my understanding such request does not exist,
since the subscription request has the corresponsing subscription
response and not subscription event.
Andrey
