Hi Cesar, the thing with roadmaps on open-source projects is sort of a "transient" thing. It can change from one day to another.
Currently we have implemented the divers we think are super-important. We'll continue to improve things but usually all new protocols I've implemented in the past few months were usually initiated by insertions of coins by companies needing drivers or by personal need. The BACnet/IP Driver for example was the result of a paid gig The KNX was a result of me wanting to talk to my house. So I think there is some set of drivers we'll be working on but the effective order can be greatly influenced by our day jobs. Chris Am 18.12.19, 17:34 schrieb "Cesar Garcia" <[email protected]>: Excellent, Do you plan to generate a roadmap with respect to the development of protocols? Thanking you for your effort, El mié., 18 dic. 2019 a las 12:26, Christofer Dutz (< [email protected]>) escribió: > 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”. > > > * Extending the API: > * We added general support for complex types (Protocols however > have to be extended to support this) > * 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) > * Refactoring the protocols > * Introduction of a SPI module > * 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) > > 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})”. > > Will continue as things come up … > > Chris > -- *CEOS Automatización, C.A.* *GALPON SERVICIO INDUSTRIALES Y NAVALES FA, C.A.,* *PISO 1, OFICINA 2, AV. RAUL LEONI, SECTOR GUAMACHITO,* *FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI* *Ing. César García* *Cel: 0416-681.03.99* *Cel: 0414-760.98.95* *Hotline Técnica SIEMENS: 0800 1005080* *Email: [email protected] <[email protected]>*
