And it seems that the folks from the Sovereign Tech Fund aren’t unhappy with me double-applying for funds. I seem to be able to define other things and align them with the NLNet stuff.
So I’ll be working on a plan to do that. Will probably define a smaller work package as if I was working on one initiative, but I guess we/I should grab all the help we/I can get. Chris Von: Christofer Dutz <[email protected]> Datum: Donnerstag, 27. November 2025 um 18:08 An: [email protected] <[email protected]> Cc: Lukas <[email protected]> Betreff: AW: My proposals for upcoming research-fund-financed work Hi, Well it doesn’t have any impact on the API. Admittedly I’m already using this in my toddysoft drivers and you can use those drivers built on the current SPI and with the new at the same time in the same JVM and users wouldn’t even notice (Except for the 90% size decrease of the jars) Regarding other languages: As this is now really self-sufficient, it’s actually going to be a lot closer to other languages’ implementations, as Netty is then no longer dominating the architecture. I could even immagine, that with these changes it’s a lot simpler to implement PLC4{whateverlanguageyouwant} as we’re no longer going to be using any libraries that we need to find counterparts in other languages. Chris Von: Lukas via dev <[email protected]> Datum: Donnerstag, 27. November 2025 um 12:20 An: [email protected] <[email protected]> Cc: Lukas <[email protected]> Betreff: Re: My proposals for upcoming research-fund-financed work Hi Chris, Your PLC4J refactoring roadmap looks great. Prioritizing removal of Netty dependency is really good. For all the rest - How much does this refactoring impact the overall API and other languages? I would vote for a release after PLC4J is Netty independent as this is a major milestone. Cheers, Lukas Am 27. November 2025 11:41:00 MEZ schrieb Christofer Dutz <[email protected]>: >Hi all, > >As many of you might know, mid of this year I applied for several public >research funding rounds with the main goal to refactor PLC4J to rid ourselves >of some of the technical debt we have piled up. Most of the work was around >rewriting the current SPI to work entirely without Netty. Beyond that to >implement a Transport layer that supports multiple connection instances to >share one transport instance (Like needed for ModbusRTU and BacNET, …) Also to >allow multiple transport instances being used by one connection instance (Like >for Profinet and Cesar’s S7 variant). > >Now it seems that both applications were judged favorably. Now I could need >some input from you guys where you see more need for cleaning up. > >So far, the tasks I applied and which I just got informed that they received >Funding are: > > > * >Implement new SPI > * >Implement new Read-/WriteBuffers that work without third party dependencies > * >Update the code generation framework > * >Implement a new system for pluggable transports > * >Implement the code for the concept of a layered protocol drivers > * >Update the existing drivers to use the new SPI > >The second package I would try to change the other would be: > > * >Implement a new Code-Generation for PLC4J based on JavaPoet (Getting rid of >freemarker (at least for Java)) > * >Implement a new connection-cache component > * >Implement a new Scraper alternative (able to use subscription-based triggers) > * >Implement a new Base-Driver that emulates subscriptions by using the new >scraper > * >Fix the issues in the S7 driver allowing us to merge the two back together > * >Add some Audit-Log functionality, that allows us to better diagnose issues > >Does that make sense from your perspective? >Anything missing you think I should focus on? > >I think a bit quicker feedback than usually here would be helpful, as I need >to finish the Sovereign Tech Fund paperwork as soon as possible. > >Chris
