alfs messaging

Bryan Dumm bdumm at bobby.bcpub.com
Wed Feb 14 00:28:54 PST 2001


Howdy,

I was talking with david via IRC about this and I think
we have some good new ideas about this....

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
expanding the extra information into the $msg itself. An error could
be 

 my $msg = {
                           type => "error"
                           msg => "Unable to change directory to $dir",
                           reason => "$!",
                           input => "retry continue quit"
                           elt => "$elt"
                           stdio => "stdio"
                           stderr => "stderr"
                           stdout => "stdout"
                           etc?
                  };

And the alfs_app could be like

$message{'$elt'} = $tag_handler->$gi($elt); # here the handler gets called

and then alfs_app does whatever with %messages. 

Speaking of "whatever", we were talking about the problems with web apps
vs other apps, and so on. What we thought we could do is this....

If $self->send_msg($msg) or whatever we call it, has a type = error or input
then send_msg also automagically attaches an id to the xml message. This id
is like "my msg_id = $elt->path . time();" with say some md5s on it to make it
really random, but a good id.... In the handler itself the call could be like

$answer = $self->send_msg($msg);

which would help us also know where in the process to continue. 

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. If it is an error or input that is going to be the only message or the 
"last message" I guess is a better way to look @ it. The frontend can say ok 
if it is an error or input I got some work to do, otherwise it just presents 
the %messages to the user. 

This is nice in that each $msg in %messages would be it's own xml object. 
This seems to be a rather easy way of hooking it back into the packages 
you are displaying to your user in the frontend. If it was an error/input
then after determining what to do, you could send back the new modified
profile that say chopped all the ok type $msg elements off, and resent the
profile. Along with that profile you sent that id which grabbed the process
back out of memory and did whatever....

So taking all that and re-doing the messaging rules how about

 1. Each handler reports either success or it's error
 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?

Bryan








More information about the alfs-discuss mailing list