plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject Re: [DISCUSS] Refactor the configuration of PLC4J drivers ...
Date Fri, 02 Oct 2020 07:40:40 GMT
In general,

if you can stand it, having a look at C code ... it might not be a bad idea to have a look
at PLC4C ... cause PLC4J is all built around Netty and you don't have that on Python.
So perhaps my "SystemTask" approach with state machines for reach type of thing might be something
you could use in Python?

Chris


Am 02.10.20, 09:33 schrieb "Lukas Ott" <ott.lukas.14@gmail.com>:

    Hi Chris,

    Yes I think this is a good idea, especially when I am thinking about our
    starting development in Python to have two separate configs for connection
    and transpor seems to be a good approach.

    Lukas

    Am Fr., 2. Okt. 2020 um 09:25 Uhr schrieb Christofer Dutz <
    christofer.dutz@c-ware.de>:

    > Hi all,
    >
    > We currently parse prepare one configuration for each connection. This
    > configuration contains all the information needed to setup the transport as
    > well as the driver itself.
    > The thing I see with this, is that the driver needs to know about all
    > transports. Now imagine we come up with some “quantum-entanglement”
    > transport … we would need to extend all drivers that theoretically support
    > that.
    > I never really was quite happy with this, I have to admit, but it worked
    > for now.
    >
    > When building PLC4C I implemented things differently.
    >
    > Here I have a parser that goes through the properties in the connection
    > url and makes this information available.
    > Now I get the driver depending on the url and this creates and initializes
    > a driver-config structure … now this can update the default properties in
    > there with overrides from the connection-url-parameter.
    > After that’s done the driver knows which transport he needs and accesses
    > that. This creates it’s own config structure and initializes that and then
    > overrides from the connection url can be applied.
    >
    > What I’m saying is: Currently we have one config … I would like to split
    > this up into a “ConnectionConfig” and a “TransportConfig” … this should
    > really separate things cleanly.
    >
    > What do you think?
    >
    > Chris
    >

Mime
View raw message