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 >>>>>>> >>>>>> >>>> >>> >>
