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 later....but 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 advice....leading me in a good direction.
On Mon, Apr 20, 2009 at 8:05 PM, Nick Perez <[email protected]> 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 <[email protected]> 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 <[email protected]> > > 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<http://search.cpan.org/%7Egwyn/POE-Component-IKC-0.2003/IKC/ClientLite.pm> > <http://search.cpan.org/%7Egwyn/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: [email protected] > http://search.cpan.org/~nperez/ <http://search.cpan.org/%7Enperez/> > http://github.com/nperez >
