On 21-01-2025 08:05, Mantas Mikulėnas wrote:
Well, at least SunRPC can have Kerberos authentication available for it (RPCSEC_GSS).
That is very interesting if you need it, in an insecure environment, like in a business. Not for me in this situation. See my other post.
At least the development environment of SUN RPC is so much outdated, it makes me cringe. For instance rpcgen still generates K&R C prototypes. I guess if you bypass rpcgen and call XDR directly, things will be better.
That's the thing I don't like from various RPC implementations. They're trying to 100% mimic local procedure calling which is impossible anyway and also requires all kinds of uglyness like program generators (rpcgen, gRPC). I only need a transport and (de)serialisation of the data. Preferrably host-bit+byte-order-independent. The multiplexing part is easy when you have simple needs.
SUN RPC has another feature compared to DBus that may be an advantage or a disadvantage. The "broker" (portmapper or rpcbind) only keeps tracks of service registration + used ports. It doesn't pass any data. This is an advantage for large data volume requirements, but for a small environments, it adds complexity (firewall, for example). IIRC you can't even assign a fixed port to a service, but this may be fixed nowadays. With DBus all servers and clients are simply connected through the broker.
I'm not sure if SOAP inherently requires a "web server"? It requires an HTTP server, yes, but that doesn't necessarily mean a whole Apache2 or IIS.
That's true, of course, but I don't know of a complete SOAP "server" that can run by itself without a web server. One could of course develop a complete SOAP server itself, which I'd gladly do, but why make the effort is something already exists that exactly does what I need: DBus. Including the "remote" part ;-)
(For my hobby projects I started with JSON-RPC over HTTPS, and ended up with JSON-RPC inside Kerberos over raw TCP – but both were almost equally self-contained "RPC servers", in that both kinds of requests were served in-process and not through any 'web' stack.)
I've done similar things. Boost has an interesting library for JSON handling. But for what I want DBus seems to be a great option. It already exists and it's an interesting opportunity to get myself familiarised with it.
