alfs messaging

Jason Gurtz jason at tommyk.com
Wed Feb 14 14:16:03 PST 2001



> K, before I had
>
> > 1. Each handler reports either success or it's error
> > 2. Alfs.pm loads up "successes" and sends them all back in one
> xml message
> > 3. Alfs.pm will stop immediately if the $msg is type "error"
> and will send
> >     the error message, profile to the alfs_app that then does whatever
> >     with it.
>
>
> Let me redefine it some.
>
> So far we have found uses for three types of ALFS xml messages.
> These are
>
> error
> msg
> input
>
> The goal here being, to keep message "types" to a minimum and
<snip>

That all seems logical  :)

> Again the alfs_app would just do whatever with %messages. Since
> the frontend
> is the one who sent the profile, they can receive these %messages
> and process
> them.

In thinking about messaging, I got to thinking genericly about tcp vs. udp
differenses, etc...
I think it would be a good thing if the messaging had tcp like QOS
guarantees in that BE sends message with MD5Sum and the FE gets that checks
the MD5Sum and if OK, sends back to the BE, "i got this OK; readyForSend()"
else "the net/commChan is FUBAR; reSendMsg()"  (or thereabouts behaviour
wise  ;)
In theory, this would really only be kinda inportent with error and input
passing, and could really get away with not having check sum and only using
unique message ID's and just answering back I recieved message with
ID#:<foo>

> So taking all that and re-doing the messaging rules how about
>
>  1. Each handler reports either success or it's error

Should their be a difference between warning and error like with compiling
or is simple pass/fail good enough?

>  2. Alfs.pm loads up everything and sends them all back in one xml message
>      (this may not be everything if an error or input occurs)
>  3. Alfs.pm will stop immediately if the $msg is type "error" or
> "input" and
>      will make an id/store the process and then send the message to the
>      alfs_app that then does whatever with it. Like send it to
> the frontend.
>      (In a console case alfs_app would be it's own frontend) :)
>
> Thoughts?

Kewl!  ;)

~jay (looking forward to tonight)

--
+------------------+
| Jason at tommyk.com |
+------------------+






More information about the alfs-discuss mailing list