Hi Julian, Wouldn't a rudimentary OPC-UA Server also do this?
A PLC4X OPC-UA Server application is one of the most asked for features from outside the community. If we built an application that for example uses Milo build a stand-alone application which offers an OPC-UA Server interface and uses PLC4X internally to communicate with other devices, wouldn't we immediately offer such support for other languages? I'm a little worried about adjusting the build to build all the different types of clients. Thrift could generate the code, but it could be challenging to build the concrete driver implementations. In the end we'll have to deal with this problem, but I think the OPC-UA Bridge would be the quickest solution which is integratable into our build and would bring the biggest benefit. Chris Am 02.11.18, 17:10 schrieb "Julian Feinauer" <[email protected]>: Hey all, I thought of our problem to currently only have support for one language (Java). For usage scenarios on “regular” devices (not embedded ones) one “simple” and “easy” way to bootstrap our current Java Implementation to other languages would be created by using Thrift or protobuf. In short, the idea is to have a Java “Server” (call it proxy or bridge) which interacts with the PLCs via our Java Implementation. Furthermore, the Java Application hosts a Server where “thin clients” in other Languages can connect and issue commands. Basically we could have Python < ------ > C++ < ------ > PlcGatewayServer < ------ > PLC C# < ------ > … (Sorry for the bad ASCII Art). Pro’s of this approach: * Is doable in “few” Time and other languags can be connected with “no effort”, even langauges like Delphi are supported (or we can use it from VBA via C# I guess). * Support for many (many) languages Cons: * Implementation not native (overhead) * Not usable on embedded devices * Separate process has to be running Overall, I think it could be worth the effort, as we would create a possibility for non JVM guys to join us and play around. What do you think? Julian
