Hello mark!
28 Oct 18 12:52, you wrote to me:
KE>> For a long term solution, convince Andrew to move the definition of
KE>> the attribute to the ctl file. But expect the answer that is was not
KE>> needed in the last 25 or so years.
ml> while i understand, it apparently has been needed... else why would we have
ml> these?
ml> submit x:y/z INTL
ml> notify errors INTL CRASH
ml> notify receipt INTL
ml> notify self INTL
You are diverting my words, I was talking about the kill sent bit not the
mechanism of send or not sending messages.
ml> if someone wanted killsent then we could have something like this...
ml> submit x:y/z INTL KILLSENT
ml> notify errors INTL CRASH PVT
ml> notify errors INTL DIRECT IMMEDIATE PVT
ml> notify receipt INTL KILLSENT
ml> notify self INTL KILLSENT
ml> in other words, turn killsent off by default and specify it if you want
ml> it... maybe LOCAL should be the only forced attribute and all the others
ml> added as above...
Your suggestion of implementation, would be correct if this would be built
in from the start. Now however it would change the default behaviour of
makenl.
The new features that have been added to makenl, have all been implemented
in such a way, that when they are not added to the control file, makenl
will ignore the feature and behave as it has always has done.
Ik my opinion that is a golden rule that should be adhered to.
ml> i don't know about others but i /want/ to see those emails that were
ml> generated... i can delete or archive them later...
You may put any emphasis on what YOU want, but that should not lead to
having all other users of makenl to suddenly have their messagebase clogged
with messages, that were automatically remove as long as makenl exists.
And ALL except you have to change their control files to get back to the
how makenl used to work.
Kees
--- GoldED+/LNX 1.1.5
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)
|
