This is fair point and I guess we reached place where we need to start
handling it, isn't it?
Currently all negotiations we have end up in "protocol logic" which
should handle that, so implementer must handle that. However if we end
up with two protocol versions where one requires some extra data, how
shall we handle that? Shall we have two separate protocol logic
implementations or find a way to cope with that in single one? If so,
who is responsible for managing type creation? I guess that S7 stuff is
close to that case, especially after insane amount of work Cesar put in
it on subscriptions. Not only that subscriptions become conditional, but
also some of the structures I think are specific to bigger PLCs.
There are many questions and I believe first implementation you working
on will show where we have gaps which needs to be filled up. Also we
don't have much of server stuff on our end, beside simulator Julien did
some time ago, so client part was a bit easier to get.
I'd say that for some of wire level operations we could have a "type
factory" and "type builder" (both likely to be generated) whereas first
would return builder for specific protocol version and later could
return structures specific for proto V1 or V2 and so on. Looking on how
much crap we sometimes need to put in protocol logic to construct each
frame it feels so wrong.
Guess that by this way we could go a little bit closer to Sebastian's
idea of generating wrappers and flows leading us towards taking ower
universe. :-)
Cheers,
Łukasz
On 28.01.2022 13:02, Christofer Dutz wrote:
Hi all,
when working on the "plc4x" protocol, Sebastian brought up a good point: The
protocol I'm implementing might need changes in the future ... how do we ensure to
support multiple versions of a protocol?
So, we extended the Protocol interface with a "getVersion()" (defaults to
returning an empty optional).
The code generation now allows providing a "protocolVersion" tag to the
execution.
If a protocol module defines a version, you need to specify the version to use
(even if there is only one). If the protocol doesn't support versions, you
shouldn't supply it.
So far it generally shouldn't have any effect on any of the existing protocols
and drivers, but we'll be extending the code generation to generate the classes
in different packages (One more level between the protocol-name and the variant.
Chris
