Hi guys,

I just sent this to Rick (on this list, too) for some new functionality for
CAF.  Basically, it sets up an 'event' queue of things like registrations
where scripts can be run periodically to do things.  The easiest example for
a generic CAF application would be registration of a new user and sending out
an e-mail with more information/confirmation/asking to click on a
confirmation link.

The rest of the examples are LPI centric but gives you an idea of what I'm
thinking.  For example, LPI has 5 (or more) scripts loading exam results from
various testing networks.  They all duplicate the sending of e-mails,
awarding of certifications (and send out more email about that).  And they
all have problems with the logic.  So, instead of fixing them all, I'm
proposing fixing the real problem.

Before we go and implement this, does anyone have comments on this approach?
Rick (and I) will add the generic support like the 'welcome' e-mail and the
queue and leave all of that exam and certification stuff in the LPI
applications.

TTYL,
Matthew

"G. Matthew Rice" <[EMAIL PROTECTED]> writes:
> Sorry, I completely forgot to send you details on what I'm thinking for the
> messaging and other event queue.
> 
> Consider the following tables (ignore the stupid field names):
> 
> table event_queue (     table event_counters (
>    id                           id/counter
>    type                         type_checked
>    other_table_id               max_checked
> )                       )
> 
> Now if you have records in the event queue like:
> 
> 1 | exam_loaded | rGtHyRe93
> 2 | cert_awarded | e$r4rgt5Gtg
> 3 | new_registration | LPI000012334
> 4 | new_registration | LPI000012345
> 
> And the counters look like:
> 
> exam_to_cert_checker | exam_loaded | 0
> new_exam_checker | exam_loaded | 0
> cert_to_cert_checker | cert_awarded | 0
> new_register_checker | new_registration | 0
> 
> And a couple of scripts.
> 
> Script 1: new_register_checker.pl
> 
>         checks the value of new_register_checker counter
>         looks for 'new_registration' events higher than the counter
>         sends out e-mails of welcoming
>         updates counter
>         exit
> 
> Script 2: new_exam_loaded_checker.pl
> 
>         check the value of new_exam_checker counter
>         looks for 'exam_loaded' events higher than the counter
>         sends out e-mails of condolences/congratulations/confirmation
>         updates counter
>         exit
> 
>         
> Script 3: exam_to_cert_checker.pl
> 
>         check the value of exam_to_cert_checker counter
>         looks for 'exam_loaded' events higher than the counter
>         determines if that new exam qualifies them for a cert
>                 (eg. they wrote 101 already, this is 102 - give a LPIC-1 cert
>                  or  they wrote 199 and have LPIC-1 - give a UCP-1 cert
>                 NOTE: I want these relationships in the DB eventually)
>         add a 'cert_awarded' event to the queue, if needed
>         send a congrats e-mail, if needed
>         updates counter
>         exit
> 
>         
> Script 4: cert_to_cert_checker.pl (more of a cleaner for people taking
>                                 exams out of order)
> 
>         check the value of cert_to_cert_checker counter
>         looks for 'cert_awarded' events higher than the counter
>         determines if that new exam qualifies them for a cert
>                 (eg. they were just awarded LPIC-1 but wrote 201/202 a year
>                         ago.  Now we can award LPIC-2)
>         add a 'cert_awarded' event to the queue, if needed
>         send a congrats e-mail, if needed
>         updates counter
>         exit
> 
> Script 5: queue_cleaner.pl (optional)
> 
>         check the lowest counter value for each event type and delete
>                 any event lower than the lowest value
>         check for types in the event queue that aren't being tracked
>                 by a counter
> 
> I think that script 1 and 5 can be part of caf proper.  Scripts 2, 3, and 4
> could be combobulated together if it made sense or even broken up more.  For
> example, the awarding of a cert and sending out the e-mail could be separate
> counters.  Maybe not a bad idea since both script 3 and 4 send award certs
> (for different reasons).  The email could be in a different simple script.
> 
> Waddya think?
> 
> TTYL,        
> -- 
> g. matthew rice <[EMAIL PROTECTED]>           starnix, toronto, ontario, ca
> phone: 647.722.5301 x242                                  gpg id: EF9AAD20
> http://www.starnix.com              professional linux services & products

-- 
g. matthew rice <[EMAIL PROTECTED]>           starnix, toronto, ontario, ca
phone: 647.722.5301 x242                                  gpg id: EF9AAD20
http://www.starnix.com              professional linux services & products
_______________________________________________
caf mailing list
caf@lpi.org
http://list.lpi.org/cgi-bin/mailman/listinfo/caf

Reply via email to