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. 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. 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. 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. It is our goal to get rid of the existing ones as soon as possible. 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
