I think this should be hosted and more importantly _maintained_ outside
the project. If you want to add reference to it to the project site or
something, that would be something to talk about.
On September 9, 2020 at 08:28:12, Stefano Bossi (stefano.bo...@gmail.com)
wrote:
Hi,
personally I think this kind of approach will limit the usability of the
library in a very narrow subset of uses do to the windows operating system
dependency.
I think you guys put a lot of effort in portability and small footprint of
the library and this is a great think in the industrial world where
typically there are small PC or embedded one.
Using the library in a small PC like a Rasperry Pi with a linux distro and
a lot of attention for the security and hardening of the environment I
think is a pro for any industrial project
(e.g. Selinux, Firewall, minimal service installation, OSCAP security
profile compliance, etc ).
Evaluating the effort required in reversing the DCOM protocol is something
to be taken into consideration before integrating a windows library in the
plc4x code.
Maybe this could be a transient solution or a way to validate a full open
source solution.
Regards,
Stefano
On 09/09/2020 13:35, Christofer Dutz wrote:
Hi Julian,
the issue I see here is that it will make the build more complex (the
part using the wrapper will only be runnable on windows and not sure
if the license of the wrapped DLLs would allow including them).
It will also eliminate the ability to auto-port the driver to other languages.
And, beyond that, it would limit these drivers to only work on a
subset of platforms (Aka ... a Java Driver that only works on Windows
Systems with installed subsystem for the PLC)
I wouldn't want to make such a solution a first class citizen (aka
live in plc4j/drivers) ... we could sort of start providing some sort
of "plc4j/contrib" modules, if we have to go this path.
But personally I would opt for at least having a look at the path I
described in slack:
- Use the native libs and build an application that does the basic
interaction with the Windows DLLs
- Use WireShark to record the communication
- Have a look if it's not just a very small subset of DCOM that is used
Perhaps it would sort of be like using some mspec types with a lot of
const fields to allow communication without any intermediate DLL ....
this would make it runnable on all target platforms and auto-portable
to all target languages of PLC4X.
Chris
Am 09.09.20, 09:50 schrieb "Julian Feinauer"
<j.feina...@pragmaticminds.de> <j.feina...@pragmaticminds.de>:
Hi all,
wanted to bring it tot he list as we already had a discussion in
the slack channel.
We have a project where we consider integrating machinery in our system.
The machinery offers an SDK for communication which is windows
only and based on DCOM.
Thus, the integration would be a wrapper around the SDK with
„only“ a PLC4X „frontend“.
Personally, I consider this viable as our aim ist o have one
interface for „everything“.
Nonetheless, I also agree with everybody saying that its not as
nice as having the complete stack in our hands.
What do others think, should this be part oft he PLC4X project or
should we just do it separately.
Personally idk that much but think it would be nice to have
maximum support in plc4x, if possible.
Best
Julian
