Oh … and one more thing: The options will be gaining a lot more weight too … in the past we only had „encoding“ for some edge-cases. Each edge-case hard-coded into the buffers. This resulted in unmaintainable buffers … when I played around with „var-length-signed-integers“ for the s7+ protocol it was a nightmare to safely integrate.
So now I defined various „WithOptions“ for this: * WithOptionFloatEncoding (applies to float mspec fields) * WithOptionSignedIntegerEncoding(applies to int mspec fields) * WithOptionUnsignedIntgerEncoding(applies to uint mspec fields) * WithOptionStringEncoding(applies to string and wstring fields) * withOptionEncoding (is sort of a shorthand to set all types of encoding to this … used for some really odd protocols, such as modbus ASCII or generally when setting only one field) Also when it came to Modbus (with these 8 or so ways of ordering bytes) I am planning on splitting up the actual encoding and the byte-order when implementing the byte buffer. So I’m planning on adding a „WithOptionByteOrder“ to control this. The idea is that when parsing, the byte-order reorders the bytes and then the encoding parses the now correctly ordered bytes. When serializing, the encoding produces the bytes and then the byte-order can reorder them for output. I played with ideas in which sequence to apply the two operations. There were by far more cases where this order is needed and I think I even only came up with theoretical ones for the other way. I hope you all agree? I guess things will become a lot clearer once you actually see the ByteBuffers in actions in the tests (the xml and box-based ones will mostly ignore most of the options and simply consume the „name“ options. So I’m not really expecting much changes there. Chris Von: Christofer Dutz <[email protected]> Datum: Montag, 8. Dezember 2025 um 10:08 An: [email protected] <[email protected]> Betreff: [SPI3] Let the fun begin :-) - First version of the buffer-API Hi all, As end of last week I finally got the NLNet paperwork finished, I used the rainy weekend to start working on the API for my planned new buffer system. So currently we have everything needed to build drivers in one big and fat SPI module. I am planning on splitting things up into individual packages, so you only need to include the pats that you need (Even if you’re using our code-generation framework and don’t want to build PLC4X drivers). This way we draw clean lines between the different parts. Admittedly in our current SPI without IntelliJs code navigation I would quite often be lost. With this we have cleaner separation of concerns, we can more easily test things. (Testing is also something … I added a 80% line coverage to my definition of done for most of the NLNet sponsored steps). So, regarding the buffers: The probably most notable changes are: * We only have BufferException instead of ParseException/SerializeException as it didn’t really bing any benefit and some times I remember being a bit lost to which was the right one (like when defining Static helper methods). * When going down in the hierarchy, we simply have pushContext and popContext (I was always confused with the previous „pullContext“ and „closeContext“ for ReadBuffers (Had to look it up, because I couldn’t remember it and I always had to look it up). The „context“ is gaining a lot more weight in the SPI3. * Another thing I updated:The „byte“ input and output is what I guess we can all consider the „primary“ format for which the entire buffer-api exists. All other formats serve the primary format. So, I moved the „logicalName“ into the options as I was sometimes confused/annoyed by having to define names for stuff used internally. Initially I was thinking of adjusting the names and value ranges of the read/write methods to the mspec nomenclature, but after first experiments, I think what we initially had was a lot less confusing. I’ve set the PR to draft … so happy to receive and integrate feedback. The next thing on my list will be to start working on the byte-based buffers for reading and writing. Chris
