#!/usr/bin/perl
use strict;
use warnings;
use SOAP::Lite;
use Data::Dumper;

my $hashref = {1 => 'one', 2 => 'two'};
my $arrayref = [1,2,3,4,5,6];

my $args = { hashref  => $hashref,
             arrayref => $arrayref};

my $soap = SOAP::Lite
    -> uri('https://domain.com/LogError')
    -> proxy('https://domain.com/path/to/logging_script');

my $res = $soap->test($args);

print $res->result;
[download]

#!/usr/bin/perl
use strict;
use warnings;
use SOAP::Transport::HTTP;
use Data::Dumper;

SOAP::Transport::HTTP::CGI
        -> dispatch_to('LogError')
        -> handle;

package LogError;

sub test {
    my ($class,$args) = @_;
    open(LOG,">>log.txt") || return "Can't open log";
    print LOG Data::Dumper::Dumper($args);
    print LOG "-"x60,"\n";
    close(LOG);
    return "Everything's OK";
}
[download]

I have no experience of POE, but am already pretty impressed with what SOAP::Lite can do. I disagree about it not being popular though - there's quite an active SOAP::Lite community out there if you go looking.

.02

cLive ;-)

update - oops, renamed server sub to make sense.

note: this is mainly a comment to the thread starter, I posted this under the wrong comment.

or ... vs

there is nothing prohibiting the combination of SOAP/Your-Favorite-RPC *and* POE as one is an event framework and the other is a RPC mechanism (and not a framework). These aren't even apples and oranges, they are apples and screwdrivers.

For RPC, I think XML over a secure channel is the way to go. It doesn't have to be SOAP, as SOAP is a designed-by-commitee protocol that tries to do much, so maybe XML::RPC will be easier. I know I prefer it if I can avoid management requirements. SOAP also is too HTTP centric, and you might not need or want the 'envelope' behavior. Those following SOAP are doing so based on the Evil Commitees That Design Things, and these folks are often not programmers who have to use the things they invent. They are often (as in my organization) overpaid meeting attenders and professional teleconference guys. Sad, but true. These are invented often for the wrong reason.

YAML

As for YAML, yes, it's nice as a config file language or for storing info... but YAML parsers are harder to come by in less cool languages (non-Perl, non-Ruby, non-Python), and it's really meant to be human editable, that's the strength -- and we don't even want human editable here. XML's strength is in extensibility, not in editablity -- and YAML is less extensible unless you confine yourself to hashes of named values. XML is supposed to be fairly tolerant of changes in information, layout, etc. That's what it does.

perl2exe

Sidenote: consider PAR as well as perl2exe. PAR is nifty.

(jeffa) You just have to do serialization yourself

Well, not exactly "yourself" and maybe not at all...XML::Simple or something could still be used, and there is this POE inter-kernel IPC I have not experimented with. But you might want to look into it. I am not sure of security implications (can you use SSL?), but essentially it passes events between POE kernels.

As for YAML, yes, it's nice as a config file language or for storing info... but YAML parsers are harder to come by in less cool languages (non-Perl, non-Ruby, non-Python), and it's really meant to be human editable

This is one of my main issues with YAML. I don't see its niche as really being needed. You can either use Data::Dumper style serializers or XML for portability. YAML seems to muddy the waters to me. Although I am sure that there are a few edge cases where something like it is necessary; I think it gets overused just for "cool factor".

... i think that using SOAP for this is overkill.

For this specific example, I'd agree, but in terms of knowing what you *could* do with it in future if needed, I think it's worth learning. I first looked at SOAP 18 months ago, and decided it was overkill for the project in hand. But I now wish I'd persevered with it. Now I understand it a bit more, it's changing my paradigm on how I view applications that need to run over a network.

It may be a sledgehammer to crack a nut, but one day you might need to smash some concrete with it (how bad can my allegories get :) and I think it's definitely a tool worth understanding - even if you reject it in this instance.

.02

cLive ;-)

server: Run this command or block of code. client: Ran it.

Please don't send code (perl or shell) over the wire. If you're using a RPC system, don't make/allow methods that accept code as a parameter. If you're rolling your own protocol, use a dispatch table of possible client requests. Make everything preset, it's easy and won't get you burnt.

Also, I highly recommend SOAP::Lite. It's very easy. You could also take a look at the PlRPC distribution; It could do the job too.