Hi Chris,
I moved the Plc{Reader,Writer,Subscriber} interfaces to the driver-base
module, where they are actually used. They are not strictly required for
protocol implementation. The SPI package now contains only the PlcDriver
interface.
Andrey
On 10/04/2018 06:19 PM, Christofer Dutz
Technically, we could do that. The API module would become cleaner and
move cohesive, but the SPI module would still depend on it.
Ideally, we would have both the API and the SPI modules independent of
each other, and the core module containing DriverManager acting as a
bridge. Though still
Hi Chris,
yeah, moving the SPI classes away from the API module is a good idea.
This would result in a clean cohesive API module for clients. However I
am not sure whethere driver-base is a good place for them, for two reasons:
1. Protocol implementers would still have to depend on both the
Hi Andrey,
I just had a second look at your proposed changes. I really like them.
I was already sort of getting annoyed by having the need to use the
PlcReader.read() method to do the read and do think your suggestion is a good
one.
One thing we could think about, would be to move all classes
Hello all,
I propose to refactor the PLC4J API and move operations PlcReader.read,
PlcWriter.write and PlcSubscriber.{subscribe,unsubscribe} for submitting
requests to the PLC away from these interfaces and place one execute()
operation directly on the request type. This has already been
skorikov opened a new pull request #27: API Refactoring: add execute operation
to requests, extract SPI package
URL: https://github.com/apache/incubator-plc4x/pull/27
API Refactoring proposal containing the following changes. The most
important changes are:
**Provide an `execute()`
Hi all,
well as it seems we will be doing our second PLC4X Meetup at the end of
November (22.11.2018 – 25.11.2018) I would need some feedback on who’s planning
on coming with how many people.
As mentioned before, the accommodation will be at the codecentric Finca and
will be free of charge
Hi all,
This is a draft for the announce email, I’m planning on sending out soon.
-
The Apache PLC4X (Incubating) team is pleased to announce the release of Apache
PLC4X (incubating) 0.1.0
Hey Chris,
thanks for the hint... I did so, you can find the branch now here
https://github.com/apache/incubator-plc4x/tree/opm-plcentitymanager
And I noticed that it ould perhaps be nice to give TL;DR; Demo on the List.
So a simple usage example (can be found in the PlcEntityManagerTest)
Hi all,
please welcome Andrey Skorikov as new Apache PLC4X Committer and PPMC.
Even if I may have already leaked this fact in my incubation report ;-)
Andrey has been very helpful with implementing the Apache Kafka Connect
integration and providing a first version of a Test-Driver that helps
Hi all,
I just wanted to tell you that we are now indexed by the Apache Kibble project
on the demo instance of Kibble:
https://demo.kibble.apache.org/dashboard.html?page=repos=plc4x
Here we can inspect commits, issues, mail activity … will definitely make
writing incubator reports easier ;-)
Hi Julian,
could you please push your branch to the plc4x repo too (You are a committer
now) ... cause this simplifies any form of "compare with branch" thing ;-)
Chris
Am 04.10.18, 08:42 schrieb "Julian Feinauer" :
Hey all,
I just finished the first (working) implementation of
Hi all,
please welcome Julian Feinauer as new Apache PLC4X Committer and PPMC.
Even if I may have already leaked this fact in my incubation report ;-)
Julian has been very helpful with discussions about PLC4X and the API
refactoring.
His company is even actively helping, by testing our drivers
Hey all,
I just finished the first (working) implementation of the Object-Plc-Mapping
(OPM).
This is a JPA Like functionality on top of plc4x which allows to issue requests
against plc4x by calling Methods on POJOs!
Basically, it uses 3 classes.
* PlcEntityManager: This is the main class.
14 matches
Mail list logo
