Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

djberg96 (2603)

djberg96
  (email not shown publicly)

Journal of djberg96 (2603)

Monday March 04, 2002
12:43 AM

SOAP, XML & RPC - some thoughts

[ #3275 ]
I'm reading about XML::RPC (ok, I was reading about the *Ruby* implementation - sue me), and while I understand what it does, I'm confused by the philosophy of the whole thing.

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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • What you're talking about sounds a bit like the REST Architectural Style [conveyor.com]. I personally think it's a much better model for computer to computer communication than SOAP/XML-RPC, in fact I've been talking about it since way before it was even called REST (my 2001 OSCon talk about "Why SOAP Sucks", which I hope to be expanding on this year).
  • Thanks for the link. What I'm planning will be even *more* flexible than simple interface genericity (at least as I understand it). There won't necessarily need to be an interface - the server will simply do what the client tells it to do (danger - "rm *" - danger). You won't have to know the methods - you can *make* the methods on the fly.

    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