Mainly, I don't understand the need to lump everything into one huge server that does *everything*, with predefined data classes to boot. Seems awfully inefficient and clunky. Reminds me of a macro-kernel approach. Not to mention the bureaucracy that will inevitably follow to actually get a method *added* to the precious server.
My plans for an RPC module will take the micro-kernel approach; keep the kernel (i.e. server) small and let the clients do the work. Let the clients define the methods/objects/code references they want to use and let the server handle them as the client wishes.
I suppose security is a big issue. But then, I've never designed a system where someone from the outside could ever get in without some other layer of security having been breached first (at which point, it would be too late anyway).
I'm really kinda excited about this. I think my idea is *better* than SOAP in some ways. Maybe I just don't fully comprehend SOAP. Maybe I'm delusional. Now, I just need some time and a flavor of *nix installed at home sometime soon.
REST (Score:2)
Interesting (Score:1)
I should say, there will at least be an *option* to set up the server that way. In a secure intranet (i.e. no outside access), I don't see this as a problem. I rea