Hi Lukasz, I'd say we continue filling gaps where we encounter them and not where we can imagine them. Right now, I would assume that we could need sort of a protocol-dispatcher in case of multiple versions/variants. That would probably be something that sits between the transport and the protocol-logic.
But let's discuss the details as soon as we encounter a need for them. What I just did was add what was needed for this case of us changing our API, which I know will happen. Chris -----Original Message----- From: Łukasz Dywicki <[email protected]> Sent: Freitag, 28. Januar 2022 14:23 To: [email protected] Subject: Re: New feature: Protocol Versions 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 >
