You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@plc4x.apache.org by Christofer Dutz <ch...@c-ware.de> on 2018/07/03 11:57:26 UTC
Refactoring the PLC4X Subscription API?
Hi all,
now digging into the subscription features of EtherNet/IP, I also had a first detailed look at the API for Subscriptions in PLC4X.
I would like to propose refactoring that a little.
I would propose to create SubscriptionRequest and -Response objects containing SubscriptionItems.
This way the API would match the Read and Write parts.
Above that it would allow subscribing and unsubscribing to multiple addresses in one request.
It would also return a response object that can be used to unsubscribe again.
The current solution, passing in the same combination of parameters to the unsubscription as used when subscribing, is a little fragile in my opinion.
What do you think?
Chris
Re: Refactoring the PLC4X Subscription API?
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Sebastian,
But "notification" on it's own is extremely generic. It could be a notification on a connection reset. The remote being unresponsive etc.
Could we aggree on SubscriptionNotification?
Chris
Outlook for Android<https://aka.ms/ghei36> herunterladen
________________________________
From: Sebastian Rühl <se...@googlemail.com.INVALID>
Sent: Thursday, July 12, 2018 2:31:47 PM
To: dev@plc4x.apache.org
Subject: Re: Refactoring the PLC4X Subscription API?
Hi Chris,
This would be a little bit better. Maybe we could even introduce sub packages? (‚read‘, ‚write‘, ’subscription’)
This way we don’t need to prefix everything. Sure when a term is to general like ‚Request‘ one should prefix it accordingly (‚WriteRequest‘, ‚ReadRequest‘, ’SubscriptionRequest’).
A Notification on the other hand is pretty unique in the meaning so we might even could omit the „Subscription*“.
Sebastian
> Am 12.07.2018 um 13:56 schrieb Christofer Dutz <ch...@c-ware.de>:
>
> Hi Sebastian,
>
>
>
> I'm not insisting on the term ... for me it was just a way to cluster the types, so everything dealing with subscriptions simply start with "Subscription" ...
>
> How about renaming SubsciptionEvent to SubscriptionNotification? But as I said, I'm not insisting on that naming convention.
>
>
>
> Chris
>
>
>
>
>
>
>
> Am 12.07.18, 09:59 schrieb "Sebastian Rühl" <se...@googlemail.com.INVALID>:
>
>
>
> Hi Chris,
>
>
>
> Looks good to me besides on small thing:
>
>
>
> Im quite more keen on using the term „Notification" instead of „SubscriptionEventItem“.
>
> If you look at other definitions this is a common used term in this space:
>
> https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern <https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern>
>
> https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn <https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn>
>
> https://docs.oracle.com/javase/7/docs/api/javax/management/Notification.html <https://docs.oracle.com/javase/7/docs/api/javax/management/Notification.html>
>
>
>
> An subscription event sounds more like a event about the subscription itself („Your subscription has been terminated“, „Your subscription has been updated“ etc) whereas the payload that is delivered through your subscription is typically a notification („Subscribe to use an receive notifications about future updates“).
>
>
>
> Any other opinions on this topic?
>
>
>
> Sebastian
>
>
>
>> Am 11.07.2018 um 17:16 schrieb Christofer Dutz <ch...@c-ware.de>:
>
>>
>
>> Hi All,
>
>>
>
>>
>
>>
>
>> I just finished refactoring the API as well as the ADS driver to match these changes.
>
>>
>
>> Both the test-suite as well as the manual tests now are executed successfully.
>
>>
>
>>
>
>>
>
>> Please have a look at the changes I proposed. Hope I didn't break anything.
>
>>
>
>>
>
>>
>
>> And it's not a final version, just a more streamlined. I guess we'll have to do the same process of getting closer to the final version in some iterations.
>
>>
>
>>
>
>>
>
>> Chris
>
>>
>
>>
>
>>
>
>>
>
>>
>
>> Am 09.07.18, 19:12 schrieb "Sebastian Rühl" <se...@googlemail.com.INVALID>:
>
>>
>
>>
>
>>
>
>> Sound good +1 from my side.
>
>>
>
>>
>
>>
>
>>> Am 06.07.2018 um 13:10 schrieb Justin Mclean <ju...@classsoftware.com>:
>
>>
>
>>>
>
>>
>
>>> Go for it
>
>>
>
>>>
>
>>
>
>>> On Fri., 6 Jul. 2018, 7:43 pm Christofer Dutz, <ch...@c-ware.de>
>
>>
>
>>> wrote:
>
>>
>
>>>
>
>>
>
>>>> Ok,
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>> I am interpreting the silence as consent and will do the changes I
>
>>
>
>>>> proposed.
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>> Chris
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>> Am 03.07.18, 13:57 schrieb "Christofer Dutz" <ch...@c-ware.de>:
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>> Hi all,
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>> now digging into the subscription features of EtherNet/IP, I also had
>
>>
>
>>>> a first detailed look at the API for Subscriptions in PLC4X.
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>> I would like to propose refactoring that a little.
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>> I would propose to create SubscriptionRequest and -Response objects
>
>>
>
>>>> containing SubscriptionItems.
>
>>
>
>>>>
>
>>
>
>>>> This way the API would match the Read and Write parts.
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>> Above that it would allow subscribing and unsubscribing to multiple
>
>>
>
>>>> addresses in one request.
>
>>
>
>>>>
>
>>
>
>>>> It would also return a response object that can be used to unsubscribe
>
>>
>
>>>> again.
>
>>
>
>>>>
>
>>
>
>>>> The current solution, passing in the same combination of parameters to
>
>>
>
>>>> the unsubscription as used when subscribing, is a little fragile in my
>
>>
>
>>>> opinion.
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>> What do you think?
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>> Chris
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>
>
>>
>
>>
>
>>
>
>>
>
>
>
>
>
>
Re: Refactoring the PLC4X Subscription API?
Posted by Sebastian Rühl <se...@googlemail.com.INVALID>.
Hi Chris,
This would be a little bit better. Maybe we could even introduce sub packages? (‚read‘, ‚write‘, ’subscription’)
This way we don’t need to prefix everything. Sure when a term is to general like ‚Request‘ one should prefix it accordingly (‚WriteRequest‘, ‚ReadRequest‘, ’SubscriptionRequest’).
A Notification on the other hand is pretty unique in the meaning so we might even could omit the „Subscription*“.
Sebastian
> Am 12.07.2018 um 13:56 schrieb Christofer Dutz <ch...@c-ware.de>:
>
> Hi Sebastian,
>
>
>
> I'm not insisting on the term ... for me it was just a way to cluster the types, so everything dealing with subscriptions simply start with "Subscription" ...
>
> How about renaming SubsciptionEvent to SubscriptionNotification? But as I said, I'm not insisting on that naming convention.
>
>
>
> Chris
>
>
>
>
>
>
>
> Am 12.07.18, 09:59 schrieb "Sebastian Rühl" <se...@googlemail.com.INVALID>:
>
>
>
> Hi Chris,
>
>
>
> Looks good to me besides on small thing:
>
>
>
> Im quite more keen on using the term „Notification" instead of „SubscriptionEventItem“.
>
> If you look at other definitions this is a common used term in this space:
>
> https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern <https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern>
>
> https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn <https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn>
>
> https://docs.oracle.com/javase/7/docs/api/javax/management/Notification.html <https://docs.oracle.com/javase/7/docs/api/javax/management/Notification.html>
>
>
>
> An subscription event sounds more like a event about the subscription itself („Your subscription has been terminated“, „Your subscription has been updated“ etc) whereas the payload that is delivered through your subscription is typically a notification („Subscribe to use an receive notifications about future updates“).
>
>
>
> Any other opinions on this topic?
>
>
>
> Sebastian
>
>
>
>> Am 11.07.2018 um 17:16 schrieb Christofer Dutz <ch...@c-ware.de>:
>
>>
>
>> Hi All,
>
>>
>
>>
>
>>
>
>> I just finished refactoring the API as well as the ADS driver to match these changes.
>
>>
>
>> Both the test-suite as well as the manual tests now are executed successfully.
>
>>
>
>>
>
>>
>
>> Please have a look at the changes I proposed. Hope I didn't break anything.
>
>>
>
>>
>
>>
>
>> And it's not a final version, just a more streamlined. I guess we'll have to do the same process of getting closer to the final version in some iterations.
>
>>
>
>>
>
>>
>
>> Chris
>
>>
>
>>
>
>>
>
>>
>
>>
>
>> Am 09.07.18, 19:12 schrieb "Sebastian Rühl" <se...@googlemail.com.INVALID>:
>
>>
>
>>
>
>>
>
>> Sound good +1 from my side.
>
>>
>
>>
>
>>
>
>>> Am 06.07.2018 um 13:10 schrieb Justin Mclean <ju...@classsoftware.com>:
>
>>
>
>>>
>
>>
>
>>> Go for it
>
>>
>
>>>
>
>>
>
>>> On Fri., 6 Jul. 2018, 7:43 pm Christofer Dutz, <ch...@c-ware.de>
>
>>
>
>>> wrote:
>
>>
>
>>>
>
>>
>
>>>> Ok,
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>> I am interpreting the silence as consent and will do the changes I
>
>>
>
>>>> proposed.
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>> Chris
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>> Am 03.07.18, 13:57 schrieb "Christofer Dutz" <ch...@c-ware.de>:
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>> Hi all,
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>> now digging into the subscription features of EtherNet/IP, I also had
>
>>
>
>>>> a first detailed look at the API for Subscriptions in PLC4X.
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>> I would like to propose refactoring that a little.
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>> I would propose to create SubscriptionRequest and -Response objects
>
>>
>
>>>> containing SubscriptionItems.
>
>>
>
>>>>
>
>>
>
>>>> This way the API would match the Read and Write parts.
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>> Above that it would allow subscribing and unsubscribing to multiple
>
>>
>
>>>> addresses in one request.
>
>>
>
>>>>
>
>>
>
>>>> It would also return a response object that can be used to unsubscribe
>
>>
>
>>>> again.
>
>>
>
>>>>
>
>>
>
>>>> The current solution, passing in the same combination of parameters to
>
>>
>
>>>> the unsubscription as used when subscribing, is a little fragile in my
>
>>
>
>>>> opinion.
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>> What do you think?
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>> Chris
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>>>
>
>>
>
>>
>
>>
>
>>
>
>>
>
>>
>
>
>
>
>
>
Re: Refactoring the PLC4X Subscription API?
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Sebastian,
I'm not insisting on the term ... for me it was just a way to cluster the types, so everything dealing with subscriptions simply start with "Subscription" ...
How about renaming SubsciptionEvent to SubscriptionNotification? But as I said, I'm not insisting on that naming convention.
Chris
Am 12.07.18, 09:59 schrieb "Sebastian Rühl" <se...@googlemail.com.INVALID>:
Hi Chris,
Looks good to me besides on small thing:
Im quite more keen on using the term „Notification" instead of „SubscriptionEventItem“.
If you look at other definitions this is a common used term in this space:
https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern <https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern>
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn <https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn>
https://docs.oracle.com/javase/7/docs/api/javax/management/Notification.html <https://docs.oracle.com/javase/7/docs/api/javax/management/Notification.html>
An subscription event sounds more like a event about the subscription itself („Your subscription has been terminated“, „Your subscription has been updated“ etc) whereas the payload that is delivered through your subscription is typically a notification („Subscribe to use an receive notifications about future updates“).
Any other opinions on this topic?
Sebastian
> Am 11.07.2018 um 17:16 schrieb Christofer Dutz <ch...@c-ware.de>:
>
> Hi All,
>
>
>
> I just finished refactoring the API as well as the ADS driver to match these changes.
>
> Both the test-suite as well as the manual tests now are executed successfully.
>
>
>
> Please have a look at the changes I proposed. Hope I didn't break anything.
>
>
>
> And it's not a final version, just a more streamlined. I guess we'll have to do the same process of getting closer to the final version in some iterations.
>
>
>
> Chris
>
>
>
>
>
> Am 09.07.18, 19:12 schrieb "Sebastian Rühl" <se...@googlemail.com.INVALID>:
>
>
>
> Sound good +1 from my side.
>
>
>
>> Am 06.07.2018 um 13:10 schrieb Justin Mclean <ju...@classsoftware.com>:
>
>>
>
>> Go for it
>
>>
>
>> On Fri., 6 Jul. 2018, 7:43 pm Christofer Dutz, <ch...@c-ware.de>
>
>> wrote:
>
>>
>
>>> Ok,
>
>>>
>
>>>
>
>>>
>
>>> I am interpreting the silence as consent and will do the changes I
>
>>> proposed.
>
>>>
>
>>>
>
>>>
>
>>> Chris
>
>>>
>
>>>
>
>>>
>
>>>
>
>>>
>
>>> Am 03.07.18, 13:57 schrieb "Christofer Dutz" <ch...@c-ware.de>:
>
>>>
>
>>>
>
>>>
>
>>> Hi all,
>
>>>
>
>>>
>
>>>
>
>>> now digging into the subscription features of EtherNet/IP, I also had
>
>>> a first detailed look at the API for Subscriptions in PLC4X.
>
>>>
>
>>>
>
>>>
>
>>> I would like to propose refactoring that a little.
>
>>>
>
>>>
>
>>>
>
>>> I would propose to create SubscriptionRequest and -Response objects
>
>>> containing SubscriptionItems.
>
>>>
>
>>> This way the API would match the Read and Write parts.
>
>>>
>
>>>
>
>>>
>
>>> Above that it would allow subscribing and unsubscribing to multiple
>
>>> addresses in one request.
>
>>>
>
>>> It would also return a response object that can be used to unsubscribe
>
>>> again.
>
>>>
>
>>> The current solution, passing in the same combination of parameters to
>
>>> the unsubscription as used when subscribing, is a little fragile in my
>
>>> opinion.
>
>>>
>
>>>
>
>>>
>
>>> What do you think?
>
>>>
>
>>>
>
>>>
>
>>> Chris
>
>>>
>
>>>
>
>>>
>
>>>
>
>>>
>
>
>
>
>
>
Re: Refactoring the PLC4X Subscription API?
Posted by Sebastian Rühl <se...@googlemail.com.INVALID>.
Hi Chris,
Looks good to me besides on small thing:
Im quite more keen on using the term „Notification" instead of „SubscriptionEventItem“.
If you look at other definitions this is a common used term in this space:
https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern <https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern>
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn <https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn>
https://docs.oracle.com/javase/7/docs/api/javax/management/Notification.html <https://docs.oracle.com/javase/7/docs/api/javax/management/Notification.html>
An subscription event sounds more like a event about the subscription itself („Your subscription has been terminated“, „Your subscription has been updated“ etc) whereas the payload that is delivered through your subscription is typically a notification („Subscribe to use an receive notifications about future updates“).
Any other opinions on this topic?
Sebastian
> Am 11.07.2018 um 17:16 schrieb Christofer Dutz <ch...@c-ware.de>:
>
> Hi All,
>
>
>
> I just finished refactoring the API as well as the ADS driver to match these changes.
>
> Both the test-suite as well as the manual tests now are executed successfully.
>
>
>
> Please have a look at the changes I proposed. Hope I didn't break anything.
>
>
>
> And it's not a final version, just a more streamlined. I guess we'll have to do the same process of getting closer to the final version in some iterations.
>
>
>
> Chris
>
>
>
>
>
> Am 09.07.18, 19:12 schrieb "Sebastian Rühl" <se...@googlemail.com.INVALID>:
>
>
>
> Sound good +1 from my side.
>
>
>
>> Am 06.07.2018 um 13:10 schrieb Justin Mclean <ju...@classsoftware.com>:
>
>>
>
>> Go for it
>
>>
>
>> On Fri., 6 Jul. 2018, 7:43 pm Christofer Dutz, <ch...@c-ware.de>
>
>> wrote:
>
>>
>
>>> Ok,
>
>>>
>
>>>
>
>>>
>
>>> I am interpreting the silence as consent and will do the changes I
>
>>> proposed.
>
>>>
>
>>>
>
>>>
>
>>> Chris
>
>>>
>
>>>
>
>>>
>
>>>
>
>>>
>
>>> Am 03.07.18, 13:57 schrieb "Christofer Dutz" <ch...@c-ware.de>:
>
>>>
>
>>>
>
>>>
>
>>> Hi all,
>
>>>
>
>>>
>
>>>
>
>>> now digging into the subscription features of EtherNet/IP, I also had
>
>>> a first detailed look at the API for Subscriptions in PLC4X.
>
>>>
>
>>>
>
>>>
>
>>> I would like to propose refactoring that a little.
>
>>>
>
>>>
>
>>>
>
>>> I would propose to create SubscriptionRequest and -Response objects
>
>>> containing SubscriptionItems.
>
>>>
>
>>> This way the API would match the Read and Write parts.
>
>>>
>
>>>
>
>>>
>
>>> Above that it would allow subscribing and unsubscribing to multiple
>
>>> addresses in one request.
>
>>>
>
>>> It would also return a response object that can be used to unsubscribe
>
>>> again.
>
>>>
>
>>> The current solution, passing in the same combination of parameters to
>
>>> the unsubscription as used when subscribing, is a little fragile in my
>
>>> opinion.
>
>>>
>
>>>
>
>>>
>
>>> What do you think?
>
>>>
>
>>>
>
>>>
>
>>> Chris
>
>>>
>
>>>
>
>>>
>
>>>
>
>>>
>
>
>
>
>
>
Re: Refactoring the PLC4X Subscription API?
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi All,
I just finished refactoring the API as well as the ADS driver to match these changes.
Both the test-suite as well as the manual tests now are executed successfully.
Please have a look at the changes I proposed. Hope I didn't break anything.
And it's not a final version, just a more streamlined. I guess we'll have to do the same process of getting closer to the final version in some iterations.
Chris
Am 09.07.18, 19:12 schrieb "Sebastian Rühl" <se...@googlemail.com.INVALID>:
Sound good +1 from my side.
> Am 06.07.2018 um 13:10 schrieb Justin Mclean <ju...@classsoftware.com>:
>
> Go for it
>
> On Fri., 6 Jul. 2018, 7:43 pm Christofer Dutz, <ch...@c-ware.de>
> wrote:
>
>> Ok,
>>
>>
>>
>> I am interpreting the silence as consent and will do the changes I
>> proposed.
>>
>>
>>
>> Chris
>>
>>
>>
>>
>>
>> Am 03.07.18, 13:57 schrieb "Christofer Dutz" <ch...@c-ware.de>:
>>
>>
>>
>> Hi all,
>>
>>
>>
>> now digging into the subscription features of EtherNet/IP, I also had
>> a first detailed look at the API for Subscriptions in PLC4X.
>>
>>
>>
>> I would like to propose refactoring that a little.
>>
>>
>>
>> I would propose to create SubscriptionRequest and -Response objects
>> containing SubscriptionItems.
>>
>> This way the API would match the Read and Write parts.
>>
>>
>>
>> Above that it would allow subscribing and unsubscribing to multiple
>> addresses in one request.
>>
>> It would also return a response object that can be used to unsubscribe
>> again.
>>
>> The current solution, passing in the same combination of parameters to
>> the unsubscription as used when subscribing, is a little fragile in my
>> opinion.
>>
>>
>>
>> What do you think?
>>
>>
>>
>> Chris
>>
>>
>>
>>
>>
Re: Refactoring the PLC4X Subscription API?
Posted by Sebastian Rühl <se...@googlemail.com.INVALID>.
Sound good +1 from my side.
> Am 06.07.2018 um 13:10 schrieb Justin Mclean <ju...@classsoftware.com>:
>
> Go for it
>
> On Fri., 6 Jul. 2018, 7:43 pm Christofer Dutz, <ch...@c-ware.de>
> wrote:
>
>> Ok,
>>
>>
>>
>> I am interpreting the silence as consent and will do the changes I
>> proposed.
>>
>>
>>
>> Chris
>>
>>
>>
>>
>>
>> Am 03.07.18, 13:57 schrieb "Christofer Dutz" <ch...@c-ware.de>:
>>
>>
>>
>> Hi all,
>>
>>
>>
>> now digging into the subscription features of EtherNet/IP, I also had
>> a first detailed look at the API for Subscriptions in PLC4X.
>>
>>
>>
>> I would like to propose refactoring that a little.
>>
>>
>>
>> I would propose to create SubscriptionRequest and -Response objects
>> containing SubscriptionItems.
>>
>> This way the API would match the Read and Write parts.
>>
>>
>>
>> Above that it would allow subscribing and unsubscribing to multiple
>> addresses in one request.
>>
>> It would also return a response object that can be used to unsubscribe
>> again.
>>
>> The current solution, passing in the same combination of parameters to
>> the unsubscription as used when subscribing, is a little fragile in my
>> opinion.
>>
>>
>>
>> What do you think?
>>
>>
>>
>> Chris
>>
>>
>>
>>
>>
Re: Refactoring the PLC4X Subscription API?
Posted by Justin Mclean <ju...@classsoftware.com>.
Go for it
On Fri., 6 Jul. 2018, 7:43 pm Christofer Dutz, <ch...@c-ware.de>
wrote:
> Ok,
>
>
>
> I am interpreting the silence as consent and will do the changes I
> proposed.
>
>
>
> Chris
>
>
>
>
>
> Am 03.07.18, 13:57 schrieb "Christofer Dutz" <ch...@c-ware.de>:
>
>
>
> Hi all,
>
>
>
> now digging into the subscription features of EtherNet/IP, I also had
> a first detailed look at the API for Subscriptions in PLC4X.
>
>
>
> I would like to propose refactoring that a little.
>
>
>
> I would propose to create SubscriptionRequest and -Response objects
> containing SubscriptionItems.
>
> This way the API would match the Read and Write parts.
>
>
>
> Above that it would allow subscribing and unsubscribing to multiple
> addresses in one request.
>
> It would also return a response object that can be used to unsubscribe
> again.
>
> The current solution, passing in the same combination of parameters to
> the unsubscription as used when subscribing, is a little fragile in my
> opinion.
>
>
>
> What do you think?
>
>
>
> Chris
>
>
>
>
>
Re: Refactoring the PLC4X Subscription API?
Posted by Christofer Dutz <ch...@c-ware.de>.
Ok,
I am interpreting the silence as consent and will do the changes I proposed.
Chris
Am 03.07.18, 13:57 schrieb "Christofer Dutz" <ch...@c-ware.de>:
Hi all,
now digging into the subscription features of EtherNet/IP, I also had a first detailed look at the API for Subscriptions in PLC4X.
I would like to propose refactoring that a little.
I would propose to create SubscriptionRequest and -Response objects containing SubscriptionItems.
This way the API would match the Read and Write parts.
Above that it would allow subscribing and unsubscribing to multiple addresses in one request.
It would also return a response object that can be used to unsubscribe again.
The current solution, passing in the same combination of parameters to the unsubscription as used when subscribing, is a little fragile in my opinion.
What do you think?
Chris