Hi, I'm generally more concerned about users expecting us to deliver feature that driver X has for driver Y too.
I won't object, if you think it's worth doing. Perhaps if you could whip up an example in a feature branch? I think perhaps I was still not understanding what you propose. Would that be ok? Chris -----Ursprüngliche Nachricht----- Von: Lukas Ott <[email protected]> Gesendet: Montag, 8. März 2021 14:20 An: [email protected] Betreff: Re: AW: Source Time of PLC Value? +1 to Lukasz Am Mo., 8. März 2021 um 14:09 Uhr schrieb Łukasz Dywicki < [email protected]>: > Hold on for a second. > > Making options pushed over connection string is a long term recipe for > disaster. Apache Camel is a prime example of what could happen if you > starting with configuration with URIs and dynamic parameters. Most of > components distinguish producer (writer) and consumer (receiver) > options, most complicated components ended up with 40+ options > settable via URI. Having a mix of PlcValues which are timestamped and > 'qualified' > and not will complicate encoding logic (how we push above info to IEC > encoder/handler or decorate it?) and how we keep custom types > compatible with above? > > That is why I rather opt for extending API in a way which does not > force existing drivers to do anything. When any of community members, > regardless if its developer or user, will find it necessary to be > ported in another driver, she or he have right to do it. It is not > only yours duty to keep all drivers and languages the same. > > Speaking of which I am also not concerned about making all languages > having the same functionality as languages tend to offer different > options which might be hard to be ported. Lets stick to basics which > are same (connection strings, field definitions, read/write/subscribe > syntax) and let various runtime lead their own ways toward implementation. > > Key point is simple - we won't be able to maintain all languages > equally. We should not hold moving ie. go or java forward because we > can't port new API functionality to C/Python/C#/whenever. If there is > someone who *does* use above in production and *wish* to have new API > parts then that person/organization duty is to do it. > > Best, > Łukasz > > > On 08.03.2021 13:17, Christofer Dutz wrote: > > Hi, > > > > I must admit that I would be in favor of keeping it as simple as > possible (max age in the connection string) and to implement more of > the missing parts in plc4x (like the subscription simulation layer) > and hereby getting the drivers we have a bit more aligned, than to > implement more and more special API features, that only one or two > drivers support. Cause this way we're running away form the > project-promise of running a given program at any type of PLC with any > protocol. > > > > I mean ... at the current velocity the project is underway, I > > wouldn't > really want to add a new MetaData layer that probably in the end only > 1-2 people will be implementing and which we must not only find out > how to fill with life in the first place, but also port to all of our > supported languages. > > > > If someone's willing to bring in some serious man/womenpower, I'm > > fine > with that ... or we add it to some wish-list for future extensions. > But I wouldn't want to start something like this right now. > > > > Chris > > > > > > > > > > > > -----Ursprüngliche Nachricht----- > > Von: Łukasz Dywicki <[email protected]> > > Gesendet: Montag, 8. März 2021 13:07 > > An: [email protected] > > Betreff: Re: Source Time of PLC Value? > > > > I have not mentioned metadata term in my answer, so credits for > > mining > it API go to you. :-) > > > > Now since you brought it I remember that JDBC has a "result set > metadata". That might be thing we still miss. The result code is most > important and available instantly, other information is supplemental > and can be read additionally. > > > > > > Best, > > Łukasz > > > > On 08.03.2021 13:01, Ben Hutcheson wrote: > >> +1 for Łukasz‘s metadata approach, it would avoid having to create > >> duplicate PLcValue classes and give us a lot of flexibility in the > future. > >> > >> On Mon, Mar 8, 2021 at 5:14 AM Christofer Dutz > >> <[email protected]> > >> wrote: > >> > >>> Hi all, > >>> > >>> sorry for being late to the party ... KNX is currently consuming > >>> all my cycles. > >>> Just wanted to add my thoughts to the discussion. > >>> > >>> Initially I thought about adding this sort of information to the > >>> API, but then I thought that we have so little protocols > >>> supporting this sort of concept that blowing up every PLCValue > >>> with this time information just would waste CPU time and Memory. > >>> > >>> When it comes to simulating subscriptions by polling in the > >>> background, I thought it would be a valid solution to provide a > >>> default age a value can have in the cache and to make it possible > >>> to override this in the connection string options. If a value is > >>> too old, > a return code of: > >>> STALE_DATA could be returned. > >>> > >>> Also, we do have an option of adding an additional set of PlcValue > types. > >>> If a driver supports this quality-of-service type of data, we > >>> could return special versions of PlcValues, that have these properties? > >>> > >>> This way we don't have to waste the CPU time and Memory for > >>> protocols that don't support this concept (We could even implement > >>> the methods on the default PlvValues to simply return some > >>> constants to the PlcValues all have the same API. > >>> > >>> Chris > >>> > >>> > >>> -----Ursprüngliche Nachricht----- > >>> Von: Łukasz Dywicki <[email protected]> > >>> Gesendet: Montag, 8. März 2021 10:43 > >>> An: [email protected] > >>> Betreff: Re: Source Time of PLC Value? > >>> > >>> Looking at issue we could utilize marker interfaces. > >>> At least in Java we could define Qualified and Timestamped types. > >>> > >>> Yet looking at present state of API we are unlikely to make each > >>> and every PlcValue in each and every variant (qualified and > >>> timestamped, timestamped, qualified). It would force quite a lot of > >>> wrapping. > >>> Safest option I see is to extend subscription/response API with > >>> additional method to retrieve all markers. For most of drivers it > >>> would return just an empty set. It leaves us also an open door for > >>> future drivers (or devices) to ship additional piece of metadata > >>> which > does not fit into present API. > >>> > >>> Best, > >>> Łukasz > >>> > >>> > >>> On 08.03.2021 04:30, Otto Fowler wrote: > >>>> So, maybe the extension is timestamp *and* timestamp source. > >>>> > >>>> uint64_t timestamp; > >>>> typedef enum { > >>>> /* timestamp was generated by the source device */ > >>>> SOURCE, > >>>> /* timestamp was generated by plc4x on receiving */ > >>>> GENERATED, > >>>> } TimestampQuality; > >>>> > >>>> > >>>> > >>>>> On Mar 5, 2021, at 18:04, Ben Hutcheson <[email protected]> > wrote: > >>>>> > >>>>> We do have some error codes, but it would just need to be > >>>>> extended a bit. I don't think we have one for BAD (we still > >>>>> receive data but the source has marked it bad). > >>>>> > >>>>> Timestamps I think are definitely a good idea, especially if we > >>>>> eventually DNP3. > >>>>> > >>>>> On Fri, Mar 5, 2021 at 5:39 PM Łukasz Dywicki > >>>>> <[email protected]> > >>> wrote: > >>>>> > >>>>>> You have response code for each individual field which allows > >>>>>> you to determine state (OK, REMOTE_ERROR etc.). Same > >>>>>> information should be available also for subscriptions. > >>>>>> > >>>>>> Best, > >>>>>> Łukasz > >>>>>> > >>>>>> On 05.03.2021 21:04, Andreas Vogler wrote: > >>>>>>> Ah, forgot: and is there a status available? > >>>>>>> Valid/invalid/good/bad > >>>>>> indicator of a plc value? > >>>>>>> > >>>>>>>> On 05.03.2021, at 21:02, Andreas Vogler > >>>>>>>> <[email protected]> > >>>>>> wrote: > >>>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> How can I get the source time of a PlcValue? > >>>>>>>> > >>>>>>>> a) from a subscription PlcSubscriptionEvent > >>>>>>>> b) from a read request PlcReadResponse > >>>>>>>> > >>>>>>>> Best regards, > >>>>>>>> Andreas > >>>>>>> > >>>>>> > >>>> > >>> > >> >
