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
