Re: Automating network testing with POE (web services IPC)

[Josh803316]

Great points and thanks for the advice!  I agree completely that it makes no
sense to plan for a complete change...I just wanted to make sure I knew
what my options were. I'm creating an automation test framework that may
turn into a complete network management system laterbut no need to put
the horse before the carriage.  I think I have seen enough to believe in the
Perl/POE/IKC approach as a very good start.  I can always speed up my actual
IKC::Lite cgi calls with fast cgi or mod_perl on the client side...and
with the POE server already running the bottleneck probably won't be the
process communication.  I really appreciate the points and the
adviceleading me in a good direction.

On Mon, Apr 20, 2009 at 8:05 PM, Nick Perez  wrote:

> Well, obviously, if you are going to be ripping out parts of your
> framework somewhere down the road, then perhaps an all-magical Perl
> application isn't your gig. I mean, sure you make everything talk some
> sort of RPC, and ultimately rip out your workers and reimplement them
> in C using libevent or whatever, but what is the benefit, especially if
> you already have a working all-magical Perl application? If you are
> concerned about performance on the worker end, perhaps you should
> encapsulate it into a simple, C, command-line utility and then have
> your workers interact with it via POE::Wheel::Run. That way the
> communication framework can remain Perl/POE/IKC. Just an idea. I just
> don't see the benefit of including some mythical event of
> reimplementing a component into your design. If you are reimplementing,
> you are likely redoing the whole approach anyway, so this becomes a
> moot point.
>
> On Mon, 20 Apr 2009 18:46:21 -0700
> Josh803316  wrote:
>
> > Nick, thanks for the help.  IKC seems great for most of this.what
> > about the future if I wanted to swap out a a perl worker for a C
> > worker? Would I use JSONRPC instead of IKC for my communication?
> > Would it be easy to mix/match?
> >
> > On Mon, Apr 20, 2009 at 5:47 PM, Nick Perez 
> > wrote:
> >
> > > It really sounds like you need to segregate the webapp from the
> > > actual daemon. And with that, you do not need to run POE within
> > > mod_perl (not that you could anyhow). But you obviously need POE
> > > communication between the web server and the POE daemon. So I
> > > recommend using POE::Component::IKC::ClientLite
> > > (
> http://search.cpan.org/~gwyn/POE-Component-IKC-0.2003/IKC/ClientLite.pm
>  >
> > > ).
> > > As for worker/controller interaction, IKC can serve those needs too,
> > > without having to involve a protocol layer beyond a TCP socket and
> > > the serializer that IKC uses.
> > >
>
>
> --
>
> Nicholas Perez
> XMPP/Email: n...@nickandperla.net
> http://search.cpan.org/~nperez/ 
> http://github.com/nperez
>

Re: Automating network testing with POE (web services IPC)

[Nick Perez]

Well, obviously, if you are going to be ripping out parts of your
framework somewhere down the road, then perhaps an all-magical Perl
application isn't your gig. I mean, sure you make everything talk some
sort of RPC, and ultimately rip out your workers and reimplement them
in C using libevent or whatever, but what is the benefit, especially if
you already have a working all-magical Perl application? If you are
concerned about performance on the worker end, perhaps you should
encapsulate it into a simple, C, command-line utility and then have
your workers interact with it via POE::Wheel::Run. That way the
communication framework can remain Perl/POE/IKC. Just an idea. I just
don't see the benefit of including some mythical event of
reimplementing a component into your design. If you are reimplementing,
you are likely redoing the whole approach anyway, so this becomes a
moot point.

On Mon, 20 Apr 2009 18:46:21 -0700
Josh803316  wrote:

> Nick, thanks for the help.  IKC seems great for most of this.what
> about the future if I wanted to swap out a a perl worker for a C
> worker? Would I use JSONRPC instead of IKC for my communication?
> Would it be easy to mix/match?
> 
> On Mon, Apr 20, 2009 at 5:47 PM, Nick Perez 
> wrote:
> 
> > It really sounds like you need to segregate the webapp from the
> > actual daemon. And with that, you do not need to run POE within
> > mod_perl (not that you could anyhow). But you obviously need POE
> > communication between the web server and the POE daemon. So I
> > recommend using POE::Component::IKC::ClientLite
> > (http://search.cpan.org/~gwyn/POE-Component-IKC-0.2003/IKC/ClientLite.pm
> > ).
> > As for worker/controller interaction, IKC can serve those needs too,
> > without having to involve a protocol layer beyond a TCP socket and
> > the serializer that IKC uses.
> >


-- 

Nicholas Perez
XMPP/Email: n...@nickandperla.net
http://search.cpan.org/~nperez/
http://github.com/nperez

Re: Automating network testing with POE (web services IPC)

[Josh803316]

Nick, thanks for the help.  IKC seems great for most of this.what about
the future if I wanted to swap out a a perl worker for a C worker? Would I
use JSONRPC instead of IKC for my communication? Would it be easy to
mix/match?

On Mon, Apr 20, 2009 at 5:47 PM, Nick Perez  wrote:

> It really sounds like you need to segregate the webapp from the actual
> daemon. And with that, you do not need to run POE within mod_perl (not
> that you could anyhow). But you obviously need POE communication
> between the web server and the POE daemon. So I recommend using
> POE::Component::IKC::ClientLite
> (http://search.cpan.org/~gwyn/POE-Component-IKC-0.2003/IKC/ClientLite.pm
> ).
> As for worker/controller interaction, IKC can serve those needs too,
> without having to involve a protocol layer beyond a TCP socket and the
> serializer that IKC uses.
>

RE: Automating network testing with POE (web services IPC)

[Nick Perez]

It really sounds like you need to segregate the webapp from the actual
daemon. And with that, you do not need to run POE within mod_perl (not
that you could anyhow). But you obviously need POE communication
between the web server and the POE daemon. So I recommend using
POE::Component::IKC::ClientLite
(http://search.cpan.org/~gwyn/POE-Component-IKC-0.2003/IKC/ClientLite.pm).
As for worker/controller interaction, IKC can serve those needs too,
without having to involve a protocol layer beyond a TCP socket and the
serializer that IKC uses.