chrisdutz commented on PR #2656:
URL: https://github.com/apache/plc4x/pull/2656#issuecomment-5102176112
Now that I had the time to catch up with everything else after my holiday
yesterday, now I had the time to thorougly read your initial message.
So the PLC4Net doesn't have to be identical to the Java version. It was
allways our goal to make the libratries feel natural in their normal ecosystem.
With Java we're using CompletableFutures, with Go we're using channels ...
whatever is the best way to do things in the target language.
What we do try to keep, is the general usage pattern: So if connections are
synchronous in Java, it would sort of be bad if it wasn't in other languages.
Also if the naming of things was kept ... like the usage of "Tag" and "Query"
and that you can add a Tag or a TagString, ....
Admittedly I don't quite understand what you mean with your first
divergence: "ConnectionString is a public type in the API, not the SPI. It has
no SPI dependency, and PlcDriverManager — which lives in the API — needs it to
route the protocol code." Could you please explain that?
I think when I did the first work on PLC4Net, I chose KNX as this used the
most of our mspec-functionality ... I thought if I get this driver working, the
rest will most probably also work. Usually when starting on a new language I
started with Modbus as this is the simplest one of them all for which a
test-bench is cheaply available. KNX also had this super odd encoding for 16
bit float which isn't really a full half-precision-iec float. In the new SPI3
java version, I think I used a dedicated float implementation:
```
['PDT_KNX_FLOAT' REAL
[simple float 16 value floatEncoding='"KNXFloat"']
]
```
The implementation is here:
plc4j/spi/buffers/byte/src/main/java/org/apache/plc4x/java/spi/buffers/bytebased/encoding/EncodingKnxFloat.java
However, I built things in SPI3 so theoretically a protocol module could
bring along it's own Encoding implementation by putting the class in the driver
module and registering it via a
org.apache.plc4x.java.spi.buffers.bytebased.encoding.Encoding property file.
As you could see I never really got very far with the .Net version as the
person that claimed to want to help decided to go away. Usually my process was
that I hand wrote some types from Modbus in the target language, then I copied
the java templates and started adjusting them till the output matched the
hand-written one. the data-io template you found was simply one copied but
never touched by me as the work stopped before I had time to do that.
As you saw on the discussion list, we're currently considering splitting out
Go and also creating go-native code generators. Possibly this is something you
would also like to do. Initially the idea was to have one system for generating
code. One system anyone would understand and maintaining would therefore be
easier. Also is it one thing to understand a programming language, but it's a
totally different thing to understand the tooling available in a language, the
best practices and how to nicely integrate this into a smoothly running build.
For java and maven we knew how to do this, for the others not so much ;-) So
the current template+maven approch was simply a quick win that we knew how to
do.
However, have I found out with my own closed-source work, that there are
huge benefits for running this in a tool-native fashion ... then I guess only
the resolution of the protocol modules would need to be implemented and the
code-gen is built per language. The mspec format is documented in an Antlr4
grammar for which there should be tooling in most languages. The core mspec
format is described here:
code-generation/protocol-base-mspec/src/main/antlr4/org/apache/plc4x/plugins/codegenerator/language/mspec/MSpec.g4
The expression syntax used in the little expression blocks inside are
documented here:
code-generation/protocol-base-mspec/src/main/antlr4/org/apache/plc4x/plugins/codegenerator/language/mspec/expression/Expression.g4
I hope I manged to answer your questions ... if not ... don't hesitate to
ask ... ideally here ... if it has to be quickly and you see I'm online in
Slack, just ask there.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
