in reply to POE vs. SOAP

I think that SOAP is better suited when you need to communicate between different programs that are implemented in different languages. It also can force some kind of standard for your clients. But from you have said, you don't appear to need that, and therefore i think that using SOAP for this is overkill. I do think that POE is an excellent choice for this problem, you just have to do the serialization yourself ... which you see from your link is not that hard thanks to YAML, which is also "smaller" than XML.

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

Replies are listed 'Best First'.
Re: Re: POE vs. SOAP
by flyingmoose (Priest) on Mar 23, 2004 at 18:40 UTC

    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.

[reply]
      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".

[reply]
Re: Re: POE vs. SOAP
by cLive ;-) (Prior) on Mar 23, 2004 at 19:35 UTC

    ... 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 ;-)

[reply]

In Section Seekers of Perl Wisdom