SPUG: Generic Client/Server building blocks
m3047 at inwa.net
Sun May 22 22:56:52 PDT 2005
At 10:22 PM 5/22/05, Brian Hatch wrote:
>I'm going to be writing two client/server apps in the
>next few weeks that are pretty dead simple[...]
>My first thoughts were to write some TCP protocol that's
>SMTP-ish. 'helo / starttls / auth / get blah / etc'.
>But then I thought that's just silly, and would be annoying
>to those folks who need to write clients in non-perl code
>because then I can't just hand them my module.
>So I was thinking SOAP, because it's all the rage. [...]
In various places in the venerable RFCs people argue that stuff should be
simple "over the wire". SOAP fails at this.
Direct argument: You still need to document your protocol. If it can be
tested and verified over the wire, this aids unit testing. With SOAP, tell
me in 6 words or less what is going over the wire (cf: "helo / starttls /
auth / get blah / etc")?
Indirect argument: Perl modules exist for SMTP, HTTP and SOAP. Since Perl
is so damned hard and it can be done in Perl, what's the problem? Are you
telling me that there is no telnet OCX? I don't believe it.
I see you're hung up on SSL, but I dismiss that as a personal whim... at
least for the sake of argument.
On a personal whim, I ask rhetorically: where is SOAP in the 7 layer model?
Isn't it really akin, in practice, to L2TP?
(Do you need YACPFW?)
fredm3047 at inwa.net (I-ACK)
 Yet another custom protocol framework. Build an IPSec tunnel if you
have to. 
 Is there no IO::Socket::INET analogue which opens SSL? I really don't know.
More information about the spug-list