Hacker News new | past | comments | ask | show | jobs | submit login

Disagree. Building XML RPC client and server requires an auth mechanism, permissions, API definitions etc.

SSH + unix + existing cli already have excellent answers to those. Plus more, like better response streaming.




In the case of XML-RPC, authentication mechanism is quite obvious: HTTP authentication. Permissions are hardly a problem, even less so than in the case of SSH, because you don't give the caller full shell, only a small set of well-defined operations. And definition of call interface does not magically go away when you move to SSH, so I don't know where did you came from with this argument.

That being said, SSH has plethora of problems as an RPC mechanism. Host key distribution sucks heavily if you have more than a handful of servers. User key distribution is even worse, unless you incorporate external mechanisms. You need to maintain a usable home directory for a service, which otherwise woudn't need such a thing. SSH has plenty of obscure functions, like port forwarding in three flavours, X11 forwarding, VPN baked in, and others. And to use SSH-as-RPC for a service you need to disable them. Are you sure you have covered every single one of them? And then there is also mixing a debugging channel with regular operations. Break just one and you cannot recover (and it's easy to break a debugging channel, as you want it reconfigured and limited to only allowed accounts and whatnot). Those two should be separated.

The only thing that SSH has better than XML-RPC is streaming a response. But first, it's a rarely used function for a setting where you need to execute a remote operation, and second, because it sometimes is actually useful, my HarpCaller (RPC daemon) needed a custom protocol.

SSH is very, very far from being an excellent protocol for running predefined remote operations, even if it were only for issues with quoting, which are difficult on their own.


> SSH is very, very far from being an excellent protocol for running predefined remote operations

Right. But then again, it's the not fully predefined operations that have the most need if escaping.


Oh, quite contrary. They do need it, otherwise you have a system that just waits for breaking apart.

However, I agree that quoting for ad-hoc synchronous commands to be run through SSH is very troublesome and tiring, especially when one doesn't understand how the commands are executed through non-interactive SSH (and most people don't).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: