Hi Chris,
if gRPC could be a match i would go first with that. I would not go the direction of implementing a complete new protocol. Rather use gRPC or MQTT. Greetings Mathi ________________________________ Von: Christofer Dutz <christofer.d...@c-ware.de> Gesendet: Freitag, 3. April 2020 16:04:23 An: dev@plc4x.apache.org Betreff: [DISCUSS] Alternatives to Thrift? Hi all, as in a few weeks my PLC4C project will hopefully entering a phase where I have to implement the “proxy” functionality, I would like to start early and discuss with you options instead of Thrift. Why not use Thrift? Well I will be targeting non POSIX systems with PLC4C. Unfortunately Thrift does have a C-GLIB client, however this code seems to utilize Boost and Boost relies on POSSIX systems so I couldn’t use it in my initiative. So I need something else … something lightweight but also something you can secure with TLS. Julian suggested gRPC It looks very promising … even if there are no native C full implementations available out there. It seems to be based on Protocol Buffers from Google. There are implementations available in C for that. gRPC seems to run over HTTP2/TCP … not quite sure if we shouldn’t just use Protocol Buffers directly? I mean we have both parts of the equation in our hands. gRPC would allow using our PLC4X proxy transport with any other gPRC client, but then we would probably lose our ability to just play around with the format. Also do I like the idea of making people use PLC4X on both sides and not just pick some parts out. What do you think? Any other transports out there that would allow secure communication between two PLC4X nodes? When doing research before starting the whole mspec thing I also had a look at Apache Avro Some more links: * https://capnproto.org/ (Authored by Kenton Varda, the primary author of Protocol Buffers version 2) * https://google.github.io/flatbuffers/ * https://msgpack.org/ * … Chris
