Hi Cesar,
I'm not saying that I won't implement the other ... of course that's the better
solution.
But for now this helps simplify things. And given that no one seems to be
willing to fund such extensions and I'm currently doing them in my free time,
I'm just postponing them in order to be a
HI,
> So my idea is to only request one byte (the ACT size) of the String and
as soon as that’s returned, to ask for only the chars that are actually
used. This should drastically reduce the payload on the wire.
I find it better to work in a two-step process as you point out.
I have my doubts ab
Hey,
I'm unemotional with your suggestion so you have my +0 there : )
Julian
Am 20.08.20, 13:27 schrieb "Christofer Dutz" :
Hi Julian,
what I didn't like with using the Array syntax was that your're not reading
an array of Strings ...
How would you read an array of strings?
Hi Julian,
what I didn't like with using the Array syntax was that your're not reading an
array of Strings ...
How would you read an array of strings?
How about using round-braces?
STRING(10)
This way you could read an array of 10-Char strings:
STRING(10)[5]
Chris
Am 20.08.20, 13:16 s
Hi,
this also was a bit controversial in the past and AFAIR we already hat
STRING[xx] as the command to not read a String Array but a String with given
size (ignoring ACT value).
In the end its about latency vs bandwith I guess.
Personally, I would stick to the rule: Read MAX either given by ST
Another alternative would be to explicitly limit the number of chars read.
So if we would extend the address syntax for STRING types to something like
%DB2:30:STRING:10
It would simply read the 10 chars without checking the size first.
Chris
Am 20.08.20, 12:44 schrieb "Christofer Dutz" :
Hi all,
while investigating: https://issues.apache.org/jira/browse/PLC4X-240 I noticed
that the reading of STRING types seems to be extremely inefficient.
The reason is that we are currently reading a STRING element by reading 258
bytes (1 byte for MAX num of chars, 1 byte for ACT num of chars
