I don't think Cesar suggestion is far from Christofer's work.
Making a context which is a glue between information known at compile
time and resolution done at runtime makes a lot of sense, since some
data might depend not only on connection setup but also on extra
resolution done on top of established connection. I could point here
recent work made by Christofer on custom/complex types for ADS which is
known only after making connection and clearly involves wire operations.
Not sure about OPC UA encryption, but from what I remember it was also
something which required a bit of adjustments from Ben.
There are more cases when serialization may require external input which
does not align with connection options or make them insane long. A prime
example could be a WM-Bus where one connection must handle multiple
encryption keys for end device's (and you may have hundreds of them).
If you ask me, getting a concept of context included in generated
serialization library, I'm all for it since it can streamline further
work in multiple areas. I'd suggest to keep it as separate SPI/API
element with known type, cause then it will be much easier to keep track
of its use across multiple places. While Map's are great giving insane
flexibility, tracing their use is extremely hard.
Best,
Łukasz
On 4.02.2023 19:19, Christofer Dutz wrote:
I'm more talking about a serialization and parse-context. Driver context would
be something separate and I think we already have that, don't we?
Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>
________________________________
From: Cesar Garcia <cesar.gar...@ceos.com.ve>
Sent: Saturday, February 4, 2023 6:47:54 PM
To: dev@plc4x.apache.org <dev@plc4x.apache.org>
Subject: Re: [DISCUSS] Generally move to using "Context" objects inside our
generated code?
+1, If there's a way to get the driver's context, something like
"PlcDriver.getContext()", and pass pipe information, interesting.
El sáb, 4 feb 2023 a las 6:18, Christofer Dutz (<christofer.d...@c-ware.de>)
escribió:
Hi all,
recently I have been working on supporting dynamic tags like “_itemCount”,
“_curItem” and “_lastItem” in array elements.
In java I used ThreadLocals for this as it felt like a Java-Native way and
it wouldn’t blow up the signatures of our Parser, Serializer and
GetLengthInXYZ methods.
Now when looking for something similar in Go, it seems in such cases
Contexts are used. These are sort of like a HashMap wrapped with little
util methods. In this HashMap you pass along values that are “in context” …
if you change the context, a copy of the old context is created and then
the updated/added values are updated/added to the HashMap.
So, in an array I add the additional information to the existing one by:
arrayCtx := spiContext.CreateArrayContext(ctx, int(_numItems),
int(_curItem))
and then simply pass in the „arrayContext”. And for accessing it I simply
for this:
spiContext.GetLastItemFromContext(ctx)
Admittedly I’m not a big fan of crating copies of the full context every
time, I would prefer to be able to push to sort of a context stack, but I
guess that’s the way things work in Go.
When I wanted to add the functionality of Java and Go to PLC4C I was a bit
stuck, as neither concept really existed.
However thinking a bit more about it, adding the concept of Contexts to C
was actually quite simple.
Now that got me thinking:
Shouldn’t we implement the same pattern for Java? It should be easy to
implement.
And while I was thinking, I even thought: Shouldn’t we extend this idea
and also get the ReadBuffer, WriteBuffer, the Encoding, the ByteOrder and
anything we’re currently passing along with “WithXYZOption” var-args, into
these Contexts and simply pass along one Context object?
I think this would clean up the code quite a bit.
What do you think?
Chris
--
*CEOS Automatización, C.A.*
*GALPON SERVICIO INDUSTRIALES Y NAVALES FA, C.A.,*
*PISO 1, OFICINA 2, AV. RAUL LEONI, SECTOR GUAMACHITO,*
*FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI*
*Ing. César García*
*Cel: +58 414-760.98.95*
*Hotline Técnica SIEMENS: 0800 1005080*
*Email: support.aan.automat...@siemens.com
<support.aan.automat...@siemens.com>*
