Hi, +1 for Julian s suggestion to use gRPC. That is one of the most promising approach, if someone else has not other suggestion.
Question: How does Apache Avro fit into that picture? (vs Parquet, Apache ORC) - > Maybe check also Apache Arrow as they aim for cross-language ? Lukas Am Fr., 3. Apr. 2020 um 16:04 Uhr schrieb Christofer Dutz < [email protected]>: > 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 >
