Re: [DISCUSS] Refactor the Subscription API

[Cesar Garcia <ce...@ceos.com.ve>]

Hi,

Interesting proposal.

In the implementation of the S7 driver (0.6.1), the subscription for
"cyclical" and "alarms / events" is functional with the existing API, but
as you point out it is very dependent on the type of "event's" supported by
the controller. In the example that is in line [1], it is the
implementation with the existing API.

In the case of Siemens, it is even a little shorter in its old API
(sapi32), it limits the use of events [2].

I will be attentive to the impact that this proposal could have since any
change in the API has an important impact on the implementation. Supporting
your proposal to carry out the most granular handling of events.

Best regards,

1.https: //
github.com/glcj/PLC4XS7Examples/blob/master/src/main/java/com/ceos/merlot/s7/PLCEventSubscription.java
2.https: //
github.com/glcj/jsapi32/blob/master/src/com/ceos/s7/sapi/SapiLibrary.java

El mar, 29 dic 2020 a las 14:03, Christofer Dutz (<ch...@c-ware.de>)
escribió:

> Hi all,
>
> while working on the initial browse API in Go, I also started thinking
> about how we could also clean up the Subscription API.
> I mentioned it before, I'm not happy with the current API, as I think it's
> far too complicated.
>
> Not even I managed to simply use it and get things right the first time.
> Usually I start having a look at how we do things in the examples and start
> using that.
>
> This is usually a signal for me that the API could use some changes.
>
> Right now, given the pretty small amount of drivers supporting
> subscriptions, I doubt many people are actually using it right now and
> doing some radical changes here soudln't harm our users. And we did say: If
> we don't know about people's usage of something because they don't publicly
> talk about it, we shouldn't worry about it.
>
> So right now we allow creating subscription requests that contain a
> mixture of "periodic", "on-value-chang" and "alarms/events". From an
> implementation perspective these are completely different types of
> subscriptions. So providing this mixture-support will definitely complicate
> things. (I think right now most drivers will only support
> "on-value-change").
>
> But then I started thinking: In which scenario would I develop an
> application that does such a mixed subscription request? I couldn't come up
> with a sensible scenario which couldn't be implemented by multiple
> subscriptions: one per each type.
>
> So I would propose to change the API in a way, that the
> SubscriptionRequestBuilder allows preparing 3 types of subscription
> requests.
>
> The part I never got right, was how we add callbacks to subsciptions.
> Currently it allows us to attach no/one/multiple handlers to subsets of
> fields of a subscription. But when would I need that in an application? Of
> course, multiple parts of an application could subscribe to different
> subsets of fields, but that would be something the driver should handle,
> and not the application.
>
> So I would propose to add a handler as argument to the "execute" method of
> the subscription request.
>
> I think this would make applications simpler, it would make the api more
> intuitive and it would help greatly clean up the implementations behind the
> request types.
>
> What do you think?
>
> Chris
>
>
>

-- 
*CEOS Automatización, C.A.*
*GALPON SERVICIO INDUSTRIALES Y NAVALES FA, C.A.,*
*PISO 1, OFICINA 2, AV. RAUL LEONI, SECTOR GUAMACHITO,*

*FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI*
*Ing. César García*

*Cel: +58 414-760.98.95*

*Hotline Técnica SIEMENS: 0800 1005080*

*Email: support.aan.automation@siemens.com
<su...@siemens.com>*