Hi Lukas, I know it's a big ball of mud. That's why I'm rebuilding it in a super modular way.
I guess my proposed changes wouldn't even effect the current buffer. I already applied changes where I renamed the "default" encoding accordingly. The only thing I'm proposing, is to explicitly define the different encodings on the root elements, that we currently have. Chris Gesendet von Outlook für Android<https://aka.ms/AAb9ysg> ________________________________ From: Łukasz Dywicki <[email protected]> Sent: Thursday, September 18, 2025 9:40:21 PM To: [email protected] <[email protected]> Subject: Re: AW: [DISCUSS] Cleanly handling encoding in mspec While I do see a point in having a separate utility to read/write signed/unsigned stuff out of buffer, I do also recognize that buffer implementations we have are quite handy on their own. I happened to use them for various small-ish tasks where I was simply to lazy to do conversions as its easy to understand project code by following signatures. Much easier with netty and their buffers. Given that buffers are part of SPI I would be careful with too fundamental changes in this area. After all, the buffer interface is similar across languages thus any changes in this area may affect templates for all languages. Side note is that while we have API for end-user applications, our SPI is pretty much big ball of mud on top of netty, and buffers are happily not polluted by it. :) Best, Łukasz On 9/17/25 18:19, Sebastian Rühl wrote: > gotcha. > > - Sebastian > > On 2025/09/17 14:08:20 Christofer Dutz wrote: >> Just noticed this was a reply to that older DISCUSS … sorry for that ... >> >> So right now, we have various types of encoding … String encoding, integer >> (signed/unsigned), float, … >> In our current Read/WriteBuffer we seem to set byte oder on a complex type >> level, but encoding only on field level. So there is no issue with this. >> However, if I want to configure the default encodings of a complex type >> (root type), I would need to set different encodings … one for signed >> integers, one for unsigned integers, one for floating point values and one >> for strings. That doesn’t work with only one „encoding“ attribute. So my >> proposal is to use „encoding“ the way we have before … it would be a >> shorthand for setting all encodings to the given one but also adding >> additional attributes „signedIntegerEncoding“ to only set that for signed >> integer values … this way the root type of a protocol could completely >> specify the default encoding implementations. >> >> So I’m proposing to add more options not remove some … the ones I’m >> proposing to add we haven’t used before as we usually hard-code those >> settings in the driver. >> >> >> Chris >> >> Von: Christofer Dutz <[email protected]> >> Datum: Mittwoch, 17. September 2025 um 15:56 >> An: [email protected] <[email protected]> >> Betreff: AW: [DISCUSS] Cleanly handling encoding in mspec >> >> Sure, >> >> So in ads.mspec we have this: >> >> [type AmsTCPPacket byteOrder='LITTLE_ENDIAN' >> >> I would propose to change it to: >> >> [type AmsTCPPacket byteOrder='“LITTLE_ENDIAN"' >> >> Chris >> >> Von: Sebastian Rühl <[email protected]> >> Datum: Mittwoch, 17. September 2025 um 15:53 >> An: [email protected] <[email protected]> >> Betreff: Re: [DISCUSS] Cleanly handling encoding in mspec >> >> not sure about the implications yet. Could you give some mspec/code examples >> with before/after? That would help a bit how that change actually affects >> stuff. >> >> - Sebastian >> >> On 2025/09/16 22:36:42 Christofer Dutz wrote: >>> Hi all, >>> >>> As you know, I’m working on a new SPI implementation, that cleanly >>> separates the byte-order and encoding from the actual read/write buffers. >>> Here I have implemented a load of encoders. The Read-/WriteBuffers are >>> currently initialized with defaults for: >>> >>> * >>> Unsigned integer >>> * >>> Signed integer >>> * >>> Float >>> * >>> String >>> >>> However in our current state we only have one „option“: „encoding“ and >>> we’re passing that along. >>> Mostly do we use „encoding=xyz“ on simple fields, but in Open-Protocol I >>> also use it on the root to set it for all fields. >>> >>> In my re-implementation I’m using the „encoding“ option to set all types to >>> a given encoding and I also have „signedIntegerEncoding“, >>> „unsignedIntegerEncoding“, … to set individual types. >>> >>> I think it would be a good idea to generally do this this way. Because then >>> the mspec already contains a lot of the information that a driver developer >>> needs. >>> >>> The idea is to do this on the root types used in the protocol. I think >>> we’re currently mostly already doing something similar with the endianness. >>> >>> So, the general idea would be that per default in my new implementation the >>> ByteBasedRead/WriteBuffer wouldn’t know what to do. If a root type defines >>> this all is good, if it’s a variable, then the driver developer needs to >>> set defaults outside of mspec. >>> >>> What do you think? >>> >>> Chris >>> >>
