Morning guys, On Thu, 2019-12-19 at 16:23 +0000, Christofer Dutz wrote: > Ok, > > so I just came back home from 3 very productive days. > I think Julian and Sebastian out did themselves with the SPI > refactoring (Driver internal API). Code is a lot cleaner now than it > was before. > Also now things nicely fit together with the generated drivers. > > I managed to finish a first functional generated S7 driver. However > we really need you folks to help out with testing it. > So far it doesn't have all the bells and whistles the old one had. > Right now it doesn't automatically split up large requests and > doesn't automatically handle the queueing of requests as the old S7 > driver did, but we're going to get to that. > > Tim has started to dig into the Modbus protocol and will probably > soon start working on this ... perhaps Alvaro and Tim can work on > this together? > I'm definitely going to be available for help. >
Sure, I would like to help on this. I plan to complete the modbus data types supported with the unsigned ones, and also, to work an issue with the writer future. But for example, if the issue with the writer future won't appear in the new refactored driver, it is better to invest time developing and testing the new driver. So Tim, what are your plans for the new modbus driver development? I can join the effort where you find it more valuable. > I'm still not 100% happy about how I'm currently converting the S7 > Data Items into PLC4X Data Items, but I think we'll be able to > finally also fix that soon. > > I know that only a part of the community working on something and > then dropping it on the rest is not the Apache Way. So I would like > to encourage you all to check what we did. > Please inspect the branch "next-gen-core" and give us feedback on it. > Ideally please test the existing drivers on this branch as there was > a lot of refactoring being done. Ok, I will take a look. What drivers are the ones we should put focus specially? > Don't hesitate to ask questions and post suggestions, if you're not > 100% happy with what we propose. > > I guess after a phase of consolidation we'll then merge the branch > back to develop and make the changes official. > Great! > Till then we'll continue fixing the old drivers if bugs are reported, > but expect the 0.6.0 branch to become the one with 100% generated > drivers. Cool, pretty ambitious. I am not aware about the timings between releases. I have analyzed the past ones, and it seems that a new release appears around each 2 months. > It is our goal to get rid of the existing ones as soon as possible. > But there are code from the existing ones that is included in the new drivers, right? Ok, I'll take a look to the work in the "next-gen-core" branch to understand the gory details. Cheers -- Alvaro > Chris > > > Am 18.12.19, 21:20 schrieb "Álvaro Del Castillo" < > [email protected]>: > > Good night! > > On Wed, 2019-12-18 at 16:25 +0000, Christofer Dutz wrote: > > Hi all, > > > > I will try to use a small phase of having to wait on others to > sum up > > what we’ve been up to. > > Currently nothing is really being done on the develop branch as > we > > will put the changes up for discussion before merging. > > The branch to watch is “next-gen-core”. > > https://github.com/apache/plc4x/tree/next-gen-core > > > * Extending the API: > > * We added general support for complex types (Protocols > > however have to be extended to support this) > > > > Nice. As we evolve on our platform, more complex types are needed > and > supported so having this kind of stuff in PLC4x will make easier > the > data processing logic after PLC4x. > > > * Cleaning up the modules > > * We moved and renamed some modules > > * All the plc4j/protocols/driver-bases/ modules are > moved > > away > > * plc4j-protocol-driver-base is now more or less the > new > > SPI module > > * plc4j-protocol-driver-base-xyz modules are now > > transport/xyz (plc4j-transport-xyz) > > Nice. > > > * Refactoring the protocols > > * Introduction of a SPI module > > I was not aware of this SPI module thing: > https://www.baeldung.com/java-spi A good pattern to hide > complexity > when implementig services following the facade approach. I like > it. > > > * Addressed common Netty problems (Buffer Leaks and > alike) > > * Abstracted the protocol layers to no longer have > direct > > dependencies on Netty stuff > > * Implementing new generated protocols > > * Implemented a version of a generated working S7 driver > which > > is able to perform connection as well as reading of values > > * We started working on a port of the Modbus driver > (Which > > previously was implemented by using an external library) > > > > Cool. I will take a look at it to play with this new version. > > > > So far from a user perspective we haven’t done any API changes > (Just > > extended: We added general support for complex data types and > data > > structures) > > > > In general we want to prevent new protocol implementers to run > into > > common Netty problems by hiding all Netty interaction behind a > new > > SPI façade. > > In the background we will be handling all of the difficult > stuff and > > the developer won’t have to think about that sort of things. > > Also are we planning on introducing a completely different way > to > > specify the logic … right now everything is encoding and > decoding > > things and the matching of response to request is some-times > tricky. > > With the proposed changes it will be similar to: > > “sendRequest(xyz).onResponse({do something})”. > > Much easier to understand and track. > > > > > Will continue as things come up … > > > > Thank you Chris for this first report. > > Cheers > > -- Alvaro > > > Chris > > >
