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