Eric Thomas <ERIC@FRECP11>
Wed, 20 May 1987 23:02 SET
|
Well, I guess I can easily provide a new return code for FAV exits in the
GET case, which means "save up the request until hh". Then I just add a
procedure to the WAKEPARM FILE, which gets called every hours, and re-issues
GET commands. Note that this would re-invoke the FAV exit (which might have
other processing to perform on the file besides queueing it out), and it
should therefore be consistent with itself and not keep postponing files for
the next hour :-)
That was one solution. Another less general one would be for the FAV to say
"ok, postpone until hh but then you don't need to call me again. Just batch
all the recipients together and send 'as is'". Then I can use DISTRIBUTE for
the batch. But I don't like it, it's too specific I think.
A last possibility is to postpone the requests, and then issue a special
form of GET command (available only internally from LISTSERV) which specifies
a list of recipients instead of just one. With that special call, the FAV gets
control with a new request type (eg GETLIST0) and decides whether it can
accept such calls or not. If it says "ok, go on", it will get called with the
standard "GET1" and "GET2" request types being changed to "GETLIST1" and
"GETLIST2" (so that it gets a chance to add info to the file), but the stuff
will eventually be batched into a DISTRIBUTE job. This will work for all FAVs
that don't perform any action that depends on the userid@node, or rather, that
don't change the contents of the file being sent depending on the userid@node
of the requestor. If this is not the case, the FAV simply rejects the
"GETLIST0" call, and the GET processor merely converts the call into a series
of individual GET for a single recipient which can be processed just as a
regular GET command.
Which solution do you prefer? Does the GETLIST stuff seem to complicated?
I'd like to provide something general if at all possible -- Kermit is not our
only application...
Eric
|
|
|