Hi Julian,


Well the reason for this was to allow explicit generic handling of the 
responses. 

There had been quite a lot of refactoring regarding this in the early times of 
PLC4X. 



I do agree that it limits the extensibility but I remember in the beginning we 
even had hard coded types so there were IntegerReadRequests and 
LongWriteRequests.

The idea behind this was to be able to have explicit control over the set of 
types used. We loosened things a little by using generics. 



The main idea behind this is, that in Java we use different datatypes as in the 
different types of PLCs. Therefore we are expecting each driver to be able to 
map certain Java types to the ones used in that particular protocol. It makes 
things a lot more complicated when allowing complex types, because every driver 
then has to know how to deal with this. In the end I was afraid to have PLC4X 
support some features on one driver and others on another. After all I haven't 
come across a single protocol, that natively supports Lists for example. 
Usually Arrays is the only thing supported. I know that OPC-UA seems to support 
datastructures as well as Beckhoff ADS (I think). So how could you change your 
code from Beckhoff to Siemens for example?



Even if no work has been done on this yet, I was always thinking of having some 
sort of mechanism on top of PLC4X that supports Datastructures and acts similar 
to how JPA does on top of JDBC. These mechanisms - which could be part of the 
PLC4X project - could for example map POJOs into Request with multiple items 
and handle the marshalling and unmarshalling transparently. Eventually PLC4X 
could also allow skipping the marshalling and unmarshalling, if the 
corresponding protocol supports complex datatypes.



What do you think?



Chris









Am 29.07.18, 13:37 schrieb "Julian Feinauer" <j.feina...@pragmaticminds.de>:



    Hi all,

    

    After going through the code I have one question about the “Typesystem”.

    From what I see, currently the java class(-name) is used as type parameter.

    Is there a specific reason for this?

    I am asking because this limits, in my eyes, the extensibility of the 
typesystem massively, e.g., for defining nullability or later on extending the 
typesystem to lists, arrays, maps or structs.

    A concrete use case would be to map a struct, e.g., in a S7 program 
directly to a struct with a shema definition given, e.g., in avro or json.

    I think this could be a pretty cool use case later on, especially when 
communication with PLCs becomes more common and TIA programmers start to 
incorporates special structs for communication.

    

    My suggestion would be to use a typesystem, e.g., similar to the one used 
in Apache Calcite 
(https://calcite.apache.org/apidocs/org/apache/calcite/rel/type/RelDataType.html
 ) and to add a static util class to convert between Java Classes and internal 
types to keep the public API’s “as is”.

    

    What do you think of this suggestion or what drawbacks do you see?

    

    Best

    Julian

    


Reply via email to