Hi all, I think PLC4X is pretty stable and major right now and we currently have two main points of improvement. First, is the generative driver topics which is “driven” by chris mostly. The other direction is to add new drivers.
But there is one thing in the API which I do not like (and which is not very good from usability standpoint) and this is the “Fields” API. I think we made a big step forward with the last refactoring we did (from Java Types to “Custom Types”). Currently PlcField is a Merker interface which bytes us on some cross cutting concerns. E.g. Tims implementation of the Triggered Scraper (PLC4X-88) is currently S7 specific, because he needs to get some information about the (parsed) Field. Furthermore, when getting a Response, the BaseDefaultFieldItem Interface is quite a Killer. So I suggest to do a (major) internal refactoring of both these (related) sides. More concrete I propose: PlcField: After parsing, each Driver should report (via PlcField) what he knows about the Field, like the Datatype (see comment below about primitive and non primitive types). Perhaps we can evene extend this to StructFields, i.e. a Field which is build on a sequence of (aligned) “primitive” Fields (although I’m unsure about the latter). BaseDefaultFieldItem: I propose to Model the Array, List or Map behavior differently than with all these getters. I would propose to have several subclasses with Methods like isArray() isList() isMap() and suitable getters (untyped) get() get(int) getMap(key) and typed getBoolean() … This could be done very similar then the RelDataType in Calcite [1](except that we would add getters). Perhaps, in the same refactoring we could even introduce a “PreparedField” or something, which would mean that there was already a round trip to the PLC and the field is “valid”, i.e. will not lead to an exception like “unknown address” or something. This is something we currently handle pretty bad in the scraper (as we do not differentiate between parsing exceptions “wrong format”, temporary exceptions “connection lost for one or two scrape cycles” or some addresses being “unknown or unreadable”). What do you others think of that? If others see this similar (I know chris told me multiple times to keep it simle but often times now this simplicity hurts us in applications) I would start to perapre a design doc in confluence. Best Julian [1] https://github.com/apache/calcite/blob/9721283bd0ce46a337f51a3691585cca8003e399/core/src/main/java/org/apache/calcite/rel/type/RelDataType.java
