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
