You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@plc4x.apache.org by Andrey Skorikov <an...@codecentric.de> on 2018/10/08 11:03:03 UTC
PlcSubscriptionEvent extends PlcReadResponse
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
Re: PlcSubscriptionEvent extends PlcReadResponse
Posted by Julian Feinauer <j....@pragmaticminds.de>.
Hi Andrey,
as I understand it this is somewhat similar of an old question of mine (for the equals method of a Request / Response).
I suggested back then to use UUIDs which chris didn’t like that much because they are too heavy (as unique ID / handle), thus we kept it as is.
But another lightweight solution would be to have a simple static final AtomicLong which is called in the constructor to enforce uniqueness in one jvm.
This could then be used as correlation id, or?
Julian
Am 08.10.18, 18:25 schrieb "Andrey Skorikov" <an...@codecentric.de>:
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" <an...@codecentric.de>:
>
> 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
>
>
>
Re: PlcSubscriptionEvent extends PlcReadResponse
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Andrey,
well I do think there is a correlation ... but you are right ... this correlation is more on Field level and after the latest refactorings we should think of removing this property from the Responses.
The "PlcField getField(String name);" should provide all the needed information. We didn't initially have that property and the path using "getRequest" was the only one available.
So yes ... we should double-check if it's needed internally, but externally I think we could remove it.
Chris
Am 08.10.18, 18:25 schrieb "Andrey Skorikov" <an...@codecentric.de>:
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" <an...@codecentric.de>:
>
> 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
>
>
>
Re: PlcSubscriptionEvent extends PlcReadResponse
Posted by Andrey Skorikov <an...@codecentric.de>.
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" <an...@codecentric.de>:
>
> 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
>
>
>
Re: PlcSubscriptionEvent extends PlcReadResponse
Posted by Christofer Dutz <ch...@c-ware.de>.
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" <an...@codecentric.de>:
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