in reply to Re: Handling asynchronous events with Perl
in thread Handling asynchronous events with Perl

Hi,

I would make a Tier based Perl solution.

I mean, having a Polling System (cron, POE, threads, maybe...), a Data Backend (some DBMS could be PostgreSQL) and a Consumer GUI which gets the info from the DB.

This way the entire program acquisition, which is the very important thing is something small and stable which doesn't depend in any way with the user interaction, or gui libs or X server. And the GUI is only a consumer from the data stored in the DB. Why a DB? Because that way you have all the data in one place, and can get the data out in some different way, more flexibility to use other custom app that would use the data for further displaying or calculations.

This schema ilustrate it:

---------------------- | data adquisition | Something small and robust. ---------------------- | / ---------------------- | db storage of data | DB backend, later you can use ---------------------- any software/language to / retrieve data, analisys, etc. | This way you're solution is ---------------------- very flexible. | GUI, consumer, etc | ----------------------

Of course only a idea... ;-)

Regards,

|fire| at irc.freenode.net

I like merlyn's disclaimer

Replies are listed 'Best First'.
Re^3: Handling asynchronous events with Perl
by zentara (Cardinal) on Jul 11, 2005 at 17:59 UTC
    Sounds like a good plan. I have noticed that big projects like the one described go through different "growth phases". First is the "proof of concept", just showing it CAN be done. Then comes the "error and exception handling" which is usually discovered during testing of the "proof-of-concept" code. It sure does pay to sit down and think a bit, before making big coding descisions.

    I'm not really a human, but I play one on earth. flash japh

      Hi,

      I'm really inspired by KISS and UNIX, modular programming, small units, etc.

      I recommend books like The Art of Unix Programming and Extreme Programming, the last one has much in common with the Unix Programming Philosophy.

      Once you start thinking about all in small pieces all at the same time seems more simple that it would be in programming bulky programs and also more robust and flexible.

      Regards,

      |fire| at irc.freenode.net I like merlyn's disclaimer