Home > Archive > PERL POE > June 2005 > Sanity Check
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Rodney Rindels 2005-06-09, 4:00 am |
| Hello Fellow POE Lovers.
I had a project dropped on my desk, after extensively reading the
requirements and reading the POE discussion groups and documentation,
I'm convinced I finally have a POE worthy project.
But. Since I Noticed Rocco mentions more than once the fact that some
things are better left to cron.. I Thought I would get the more
experience POE users opinion on this one.
Basically I need to build an Event Based, Web Attached (for Management),
FTP, SFTP,WWW::Mechanize, Expect, and Serial Device Controlled framework.
A few features of the requirements are ability to start, stop, and
restart from web console, as well as pull statistics and dynamic
reconfiguration.
Centralized logging to x,y, or z (Ie. Could be syslog, could be flat ,
could be database).
Persistant Database Connections
And the ability to connect and transfer files to x number of system
types based off either custom scripts or Centralized with Configuration
files driving the changing pieces.
I started down the road of building at least (what I think) could be a
core to keep the daemon running properly where I build _start event
which kicks off kernel delay to call _start again every so often.
Thoughts, Suggestions, Therapy?
Rodney
| |
| Wiggins d'Anconia 2005-06-09, 4:00 am |
| Rodney Rindels wrote:
> Hello Fellow POE Lovers.
>
> I had a project dropped on my desk, after extensively reading the
> requirements and reading the POE discussion groups and documentation,
> I'm convinced I finally have a POE worthy project.
>
> But. Since I Noticed Rocco mentions more than once the fact that some
> things are better left to cron.. I Thought I would get the more
> experience POE users opinion on this one.
>
Sounds like a project for POE to me, certainly beyond cron's abilities,
sure you could do it that way but it would be a nightmare.
> Basically I need to build an Event Based, Web Attached (for Management),
> FTP, SFTP,WWW::Mechanize, Expect, and Serial Device Controlled framework.
>
wowzers, you forgot the kitchen sink. Make sure to use CPAN to its
fullest with the above list, pretty sure everything is covered.
> A few features of the requirements are ability to start, stop, and
> restart from web console, as well as pull statistics and dynamic
> reconfiguration.
>
> Centralized logging to x,y, or z (Ie. Could be syslog, could be flat ,
> could be database).
>
Definitely check out Log4perl, http://log4perl.sf.net , it should help
you accomplish the above in a very very nice way with minimal coding by
you. I have used POE with Log4perl before and it was a dream.
> Persistant Database Connections
>
> And the ability to connect and transfer files to x number of system
> types based off either custom scripts or Centralized with Configuration
> files driving the changing pieces.
>
I hate to say it but with all your various systems, protocols, etc. I
would start from scratch with an XML based config system. I don't throw
out XML lightly as I think it is overkill for a lot of things, but with
all the different setups you are talking about it can be very effective.
XML::Simple should do nicely.
> I started down the road of building at least (what I think) could be a
> core to keep the daemon running properly where I build _start event
> which kicks off kernel delay to call _start again every so often.
>
> Thoughts, Suggestions, Therapy?
>
The only thing I would say specifically about POE, and I have said it
before, is use the object wrapped sessions. The regular subroutine
based sessions are nice for simple and small projects, or examples like
those in the cookbook. But using the object based ones have made life so
much easier for me in the past. No need to meddle in the HEAP and
passing a bunch of values around. It allows you to restrict the events
to things that should normally be firing events, and lets everything
else that would normally just be a method call to an object remain as
such, don't use a bunch of event calls just to pass values/objects
around, etc. Just my $.02.
> Rodney
>
>
Good luck.
http://danconia.org
| |
| Matt S Trout 2005-06-09, 4:00 am |
| On Sat, Apr 30, 2005 at 10:19:04AM -0500, Wiggins d'Anconia wrote:
> I hate to say it but with all your various systems, protocols, etc. I
> would start from scratch with an XML based config system. I don't throw
> out XML lightly as I think it is overkill for a lot of things, but with
> all the different setups you are talking about it can be very effective.
> XML::Simple should do nicely.
At least a couple of people are using my Class::XML to automatically load
a tree of config objects from an XML file in a relatively clean format. I
find it much less of a pain in the neck, anyway :)
--
Matt S Trout Brag sheet: http://trout.me.uk/services.html
LAMP, Infrastructure Contact: services@trout.me.uk
and Automation
specialist Do it once. Do it right.
| |
| Wiggins d'Anconia 2005-06-09, 4:00 am |
| Matt S Trout wrote:
> On Sat, Apr 30, 2005 at 10:19:04AM -0500, Wiggins d'Anconia wrote:
>
>
>
> At least a couple of people are using my Class::XML to automatically load
> a tree of config objects from an XML file in a relatively clean format. I
> find it much less of a pain in the neck, anyway :)
>
Looks interesting, more complex than I have ever needed. And I have
never really used Class::DBI so it wouldn't be an easy jump for me. But
I will certainly consider it in the future, especially for anything
complex I get into. Been meaning to take Class::DBI for a test drive too.
http://danconia.org
| |
| Rodney Rindels 2005-06-09, 4:00 am |
| Matt S Trout wrote:
>On Sat, Apr 30, 2005 at 10:19:04AM -0500, Wiggins d'Anconia wrote:
>
>
>
>At least a couple of people are using my Class::XML to automatically load
>a tree of config objects from an XML file in a relatively clean format. I
>find it much less of a pain in the neck, anyway :)
>
>
>
Yeah I'm sure i'm in over my head on this one :-). I'll take a look at
Class::XML though, this almost goes beyond the XML::Simple comfort level.
Thanks Everyone.. I'm POE'ing away now. Sure I will have 100 Million
questions before this one is done.
Rodney
| |
| Bas Schulte 2005-06-09, 4:00 am |
| Hi,
On 30-apr-05, at 1:27, Rodney Rindels wrote:
> But. Since I Noticed Rocco mentions more than once the fact that some
> things are better left to cron.. I Thought I would get the more
> experience POE users opinion on this one.
You can combine cron and POE nicely, I just did it in a scheduler-like
application. It's a POE app with delayed events etc.. It gets it's
schedule from a database table, those entries are converted to cron
lines (e.g. "*/5 1 0 0 0"), these lines are fed to
DateTime::Event::Cron that calculates the timestamp of the "next
interesting" datetime.
Every 5 or so seconds, I re-scan the database tables to see if there
were schedule changes, and if so, adjust that "next interesting"
datetime.
When the "next interesting" time has come, I start the specified task
(in my case, I open a tcp/ip network connection to a local control
server, also a POE app, and tell it to do something.
It beats the hell out of regular cron, flexibility-wise ;)
Cheers,
Bas.
| |
| Rodney Rindels 2005-06-09, 4:00 am |
| Bas Schulte wrote:
> Hi,
>
> On 30-apr-05, at 1:27, Rodney Rindels wrote:
>
>
>
> You can combine cron and POE nicely, I just did it in a scheduler-like
> application. It's a POE app with delayed events etc.. It gets it's
> schedule from a database table, those entries are converted to cron
> lines (e.g. "*/5 1 0 0 0"), these lines are fed to
> DateTime::Event::Cron that calculates the timestamp of the "next
> interesting" datetime.
>
> Every 5 or so seconds, I re-scan the database tables to see if there
> were schedule changes, and if so, adjust that "next interesting"
> datetime.
>
> When the "next interesting" time has come, I start the specified task
> (in my case, I open a tcp/ip network connection to a local control
> server, also a POE app, and tell it to do something.
>
> It beats the hell out of regular cron, flexibility-wise ;)
>
> Cheers,
>
> Bas.
>
>
>
I think this idea has some merit for the complex timing issues I'm going
to have. I can also store run state in the database then and keep "like"
events from firing on top of each other.
Thanks......
Rodney
| |
| Rocco Caputo 2005-06-09, 4:00 am |
| On Fri, May 06, 2005 at 03:14:18PM +0200, Bas Schulte wrote:
> Hi,
>
> On 30-apr-05, at 1:27, Rodney Rindels wrote:
>
>
> You can combine cron and POE nicely, I just did it in a scheduler-like
> application. It's a POE app with delayed events etc.. It gets it's
> schedule from a database table, those entries are converted to cron
> lines (e.g. "*/5 1 0 0 0"), these lines are fed to
> DateTime::Event::Cron that calculates the timestamp of the "next
> interesting" datetime.
>
> Every 5 or so seconds, I re-scan the database tables to see if there
> were schedule changes, and if so, adjust that "next interesting"
> datetime.
>
> When the "next interesting" time has come, I start the specified task
> (in my case, I open a tcp/ip network connection to a local control
> server, also a POE app, and tell it to do something.
>
> It beats the hell out of regular cron, flexibility-wise ;)
Sounds nice! Have you seen POE::Component::Cron?
--
Rocco Caputo - http://poe.perl.org/
| |
| Bas Schulte 2005-06-09, 4:00 am |
| Hi Rocco,
On 7-mei-05, at 0:48, Rocco Caputo wrote:
> Sounds nice! Have you seen POE::Component::Cron?
Hmmmz. Nope :)
When I was in the design phase of this project, I took my first steps
towards using POE. I intended to use POE for another component (control
server; manages sessions running on TV based on
POE::Component::Server::TCP/POE::Wheel::Run). Whilst learning POE for
that component, I was also working on the scheduler which was
originally not meant to use POE. Which is probably why I hadn't see
POE::Component::Cron.
It's all water under the bridge by now as far as I am concerned: I just
quit my current job to emigrate into New-zealand (from the Netherlands)
;) Yeehaw!
Cheers,
Bas.
|
|
|
|
|