I believe that there are a couple of more things which could be placed there. We have same type names between different PLCs (BOOL, UINT, SINT, and so on), however these are distinct between modules having no common parent type. The AdsDataType has very little in common with S7 TransportSize making it fairly difficult to unify some of configurations handling. More over by making type handling one of core elements we will be able to unify some of bit shifting mambo-jambo related to mapping byte to signed/unsigned variants. I know that's not the case for most JDBC drivers however the API and implementations there diverge a lot as they are handled in separate places by database vendors. Since we have a luxury of handling couple PLC kinds in same projects we can take benefits of (some) unifications.
Personally I am more convinced to module which would cope with that which would be separate from other utils (ie. transport related). Utils types and module/package kinds have a tendency to gather lots of fat over time and degrade rather quickly. We don't have to be shy of having a module with one-two packages and couple of classes as twisting dependency paths is then much easier. If we keep it close to other utils we will make it more difficult. Ie. maybe now we will have driver > plc4j-types > plc4j-spi > plc4j-api path but later it can be easily flipped to driver > plc4j-spi > plc4j-types > plc4j-api. Cheers, Łukasz czw., 2 sty 2020 o 11:03 Julian Feinauer <j.feina...@pragmaticminds.de> napisał(a): > Hi, > > fully agree with both of you. > The more we generify the better (yeah, mathematician talking here...). > I think the optimal way would to have a layer or Utils module where we > already provide tons of "standards" to serialize types and which is > pluggable so that protocols can also add their weird implementations for > specific things. > This goes in the direction of Cesars link, I think. > > Julian > > Am 28.12.19, 16:44 schrieb "Cesar Garcia" <cesar.gar...@ceos.com.ve>: > > Hi everyone, > > I think that the second option, using some type of standard definition > for > "plc4x-types", may facilitate the development of protocols. > > As an example the definition of Scalar types in [1]. > > Best regards, > > 1. > > http://epics-pvdata.sourceforge.net/alpha/normativeTypes/normativeTypes.html > > > > El sáb., 28 dic. 2019 a las 4:19, Christofer Dutz (< > christofer.d...@c-ware.de>) escribió: > > > Hi all, > > > > while porting the code to use the PlcValue objects I did notice when > > updating all existing PlcFieldHandlers that the code looks sort of > almost > > the same. > > While I would say the S7FieldHandler is by far the most advanced one > > (actually checking the data has the right type and doing range > checks for > > every element). > > > > How about moving most of this code to a base class? > > I did notice that an essential part of this are the internal types > defined > > by every protocol. But these types might have different names, but in > > general they do have the same meaning. > > > > So how about we define an Enum with the different types and then > either > > use them in the drivers or simply provide a mapping of driver types > to > > plc4x-types? > > > > I know that writing the FieldHandler was something that required a > lot of > > code and coding … this way we could reuse the code and simplify > things > > greatly when writing new drivers? > > > > Of course will there be fields that don’t fit this schema, > especially for > > KNX and BACnet, but most of the other drivers could easily reuse the > code. > > > > 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: 0416-681.03.99* > > *Cel: 0414-760.98.95* > > *Hotline Técnica SIEMENS: 0800 1005080* > > *Email: support.aan.automat...@siemens.com > <support.aan.automat...@siemens.com>* > > >
