Hi Chris,
thank you SOO much for all the "housekeeping".
Indeed, during the refactoring we were very focused on specific things and code
quality or consistency was not the major goal, so you did a lot here.
And indeed, we merged together multiple modules (and created other ones) so
that the structure of the project hopefully is more easily understandable (like
explicit transports).
After seeing your work now, I also agree with your approach of doing this
transport thing, its cleaner that way overall.
I will have a look at the branch and probably add some comments.
Thank you soo much!
Julian
Am 12.01.20, 13:30 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:
Hi all,
so as I mentioned in the last email about the scraper, I have invested
about 7 full days in cleaning up the SPI module after the refactoring session.
Now hopefully I have untangled some of the code that made it extremely hard
to understand for me (And probably others).
I cleaned up in the packages quite a lot as Sebastian told me that the
current structure was a result of “just merging multiple old module”.
I hope it’s a big step forward regarding maintainability of the SPI.
Also did I remove all deprecated stuff in the SPI. I think if we’re
currently going to release all drivers in new versions anyways, there is no
need in porting the old ones and then deleting them.
The changes that we would have needed would have been significant. So now
only the next-gen drivers are enabled and all the old ones are commented out of
the build (not deleted yet)
I also introduced the concepts of “transports” even if this concept was
previously sort of there already, but it wasn’t exposed very well. Now every
driver can define a default transport.
Here for example S7 would define “tcp”, BACnet/IP would define “udp”,
AB-ETH would define “serial” … and a connection string like: s7://1.2.3.4 would
directly use TCP with a default port of 102.
But we can now override the transport: s7:raw://if4 would use the same S7
driver but use a raw-socket using the network device “if4” for capturing.
Interesting for testing will be the “pcap” transport.
Here you provide a path to a pcap file in the url and it will replay that
as if it were a real “raw” transport.
Every transport defines a Config interface which can provide additional
information such as the default-port for tcp, the replay-speed for pcap etc.
The driver configurations can implement these interfaces (but don’t have
to).
A configuration can implement the transport config interfaces of multiple
transports.
As the changes were so significant (I think about 250 changed files) … I
decided to create a new branch so you can compare the branches.
Please review them and especially test your drivers … I don’t think that my
port of all of them was 100% successful, but sometimes I didn’t have the
hardware.
Chris
