In message <9406222314.ZM27376@hplabsz.hpl.hp.com>,
"Laura de Leon" writes:
>On Jun 22, 5:52pm, John P. Rouillard wrote:
>> Subject: Re: importing/exporting variables
>>
>> Do you mean the body of the incomming message, or the outgoing message?
>> Could you clarify your "info" example a bit?
>>
>I meant the newinfo command. I was thinking of the body of
Yup, I just realized what you meant in the shower this morning.
>the message. I just realized
>that it really won't be the body, it should be part of the arguments
>since newinfo is expecting the newinfo to the end of the message
>or the EOF marker.
Actually, not. Newinfo reads from <STDIN> after it is called from the
main dispatch loop. &newinfo is responsible for reading the message up
to the EOF marker, the dispatch loop/switch is only responsible for
recognizing the:
newinfo bblisa passwd
line in the incomming text, and calling &newinfo with the list name
and the password.
>I do expect that someone will come up with a reason in pre or post
>function that will want to the body of the original
>message.
Probably, the only problem is that the message is currently read in
incrmentally as needed from STDIN. Maybe we should change it so that it
reads the whole message from STDIN, stores it, and then analyzes
it. The one problem with this approach is that we may need both a disk
based and a memory based way of doing this. Imaging having a 1000 line
majordomo message (quite possible for sites that batch their sun/unsub
requests). Do we really want al of that message in core? What about
machines that are low on memory space? As it currently stands sendmail
is nice enough to store the message on disk for us, and feed it to us
on STDIN, sadly we can't use that file directly 8-(.
>My quick summary so far:
>
>These are the readonly variables needed:
>
> %Email_Headers will contain the headers keyed with
>header names, e.g %Email_Headers{'from'} will return the
>from header if it exists
>
> @Email_Body will contain a copy of the message body
Or at least a copy of the message that has been currently
read. Considering the potential size of @Email_Body, would it make
sense to throw some access functions around it so that we can make the
array "disk based" for those machines that don't have lots of memory.
>[perhaps %Email could contain the headers and @Email would
>contain the body?]
Sounds reasonable.
>These are the Read write variables needed:
>
> There should a standard set of arguments and variables
>available for each function. Things that come to mind are
>
> $Command [the name of the command]
> (this might be needed for command aliases, for
> instance)
Actually I was just planning on passing this in as the first argument
to the pre/post functions.
> $Listname [the name of the list as derived so far]
There should also be a "default-listname" that contains the list as
specified by the -l argument to majordomo.
> $Reply_to [who is going to get the result of the command]
Is this the same as the person majordomo believes is sendding the request?
> $Approved [should the command be allowed, this should allow
> generalization of the approve command]
> @Args [the rest of the arguments]
> @Result [the output of the command]
>
>These would be reset for each command.
I assume you mean @Args and @Result would be reset for each
command. If $Approved etc were reset then it would be difficult to
approvve anything.
>Laura points out that it might be useful to have some indicator
>for which line is being processed from the body of the message.
Yes, I could see that. Possibly also a count of the number of commands
processed (increment by one upon entering the dispatch loop). This
allows one to prevent denial of service attacks by limiting the number
of operations that can be done.
-- John
John Rouillard
Senior Systems Consultant (SERL Project) University of Massachusetts at Boston
rouilj@cs.umb.edu (preferred) Boston, MA, (617) 287-6480
==============================================================================
My employers don't acknowledge my existence much less my opinions.
References:
|
|
