Hi Chris,
the new Scraper IS currently S7 specific, yes.
This is why I want such a refactoring to make it unspecific (because I also
don’t whant it that way).
The reason for this is the following code.
```
this.s7Field = S7Field.of(triggerVariable);
```
Together with the more crucial
```
switch (this.s7Field.getDataType())
```
(both Snippets from TriggerConfiguration.java).
So now you may see why I propose to add some kind of "getDataType()" to the
PlcField interface, as this would fix everything and keep things generic.
Of course we need to do it with a bit of a feeling, as all these PLCs may have
different types or type-systems, but I'm thinking of it : )
Julian
Am 07.03.19, 09:53 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:
Hi Julian,
the new Scraper is S7 specific? Was the old one too? Just asking, cause I
don't really like the idea of having protocol-specific tools as it's the whole
point of PLC4X to be unspecific.
Regarding the other topics ... I sort of couldn't immediately wrap my head
around that ... could you maybe do a branch where you have your proposed
changes (doesn't have to work) ... so we can see the difference?
I guess we can understand much easier what you have in mind that way.
But in general I think it's a good idea to support structures (Are you
thinking of structures the way they are handled in C ... where there's simply
an array of bytes and the "struct" lays a pattern/template/stencil on that and
allows to to access individual fields.
I think this would be a great feature ... especially as we could use this
for automatic optimizations of request (automatically generate a struct if this
is more efficient then loading individual fields on their own).
Chris
Am 07.03.19, 09:21 schrieb "Julian Feinauer" <j.feina...@pragmaticminds.de>:
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
