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 <christofer.d...@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" > <sebastian.ruehl...@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 <christofer.d...@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" >> <sebastian.ruehl...@googlemail.com.INVALID>: > >> > >> > >> > >> Sound good +1 from my side. > >> > >> > >> > >>> Am 06.07.2018 um 13:10 schrieb Justin Mclean <jus...@classsoftware.com>: > >> > >>> > >> > >>> Go for it > >> > >>> > >> > >>> On Fri., 6 Jul. 2018, 7:43 pm Christofer Dutz, <christofer.d...@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" <christofer.d...@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 > >> > >>>> > >> > >>>> > >> > >>>> > >> > >>>> > >> > >>>> > >> > >> > >> > >> > >> > >> > > > > > >
