(.tsl -> .proto) = gRPC?

[PawelBaranowski]

First of all, thanks for keeping this project alive. It seems like a fascinating piece of technology and it would be a shame if it just disappeared.

I'm currently getting to know GE and while looking at TSL it's hard not to draw similarities to Protocol Buffers. I'm wondering if it would be a good (and doable) idea to create an extension (think GraphEngine.Protobuf) to automatically translate .tsl into .proto in order to take advantage of the awesome support of gRPC in .NET. It would make GE easily accessible for any gRPC-enabled client software together with any security-related shenanigans. I feel like this could help bring more attention to GE.

There's also another, more drastic possibility, to simply drop TSL in favor of Protocol Buffers, which is a widely recognized and supported language for specifying data and operations contracts. What do you think? Is TSL worth keeping alive or is it going to be dead-weight? Maybe I'm missing something and there are some features of TSL impossible to implement in Protocol Buffers?

[PawelBaranowski]

There's one more thing on my mind. I have no idea how communication is implemented in GE, so excuse me if I'm missing the point. Would gRPC be a good candidate for client-server and server-server communication? If so, it could reduce maintenance costs by simply relying on gRPC for communication. Why reimplement security features if there are ready-made solutions?

Time and effort saved due to reusing a communication protocol could be invested in core GE's functionality.

[TaviTruman]

@PawelBaranowski Welcome to what I believe is one of the most fantastic sleeper software technology these days and welcome to the amazing world of Graph Engine computing. So, as you are new to the Microsoft Trinity Graph Engine, there is a lot to cover here. Firstly, GE TSL and Protobuf may seem the same, but they aren't close. However, the GE networking substrate is extensible, and gRPC and the GE can coexist. I wrote a WCF wrapper a few years ago, but we halted that development with the advent of gRPC. I don't have the time to address the whole of things right now as I'm just about to release another beta release of enterprise-grade technology that is 100% Graph Engine enabled - it is Awesome!

[TaviTruman]

FYI - the GE Communications architecture, design, and implementation is written in C++ and works over low-level TCP and HTTP/RESTful. It is extensible so that you can implement gRPC. The OOB communications implementation is one of the best I've ever seen in over 30+ years of distributed client/server programming and cut my teeth on IBM DCE/RPC & CORBA back in the day. The GE communications model is lightweight, fast, efficient, and supports symmetric network computing.

[PawelBaranowski]

Please forgive my newcomer's questions, I've only learned about GE's existence yesterday. I promise I'll learn about TSL and never underestimate it again 😉
Thanks for explaining some internals of GE's communication layer, I understand it doesn't need a replacement. However, I still see value in using gRPC for client-server communication, alongside REST.