John Simpson wrote:
i can understand this. however, since the call_onchange() function
waits for the script to complete, it is up to you as the author of an
onchange script to make it run as quickly as possible. as i explained
before, my "onchange" script sends its command line arguments to a
named pipe and exits, and the service which is listening to the other
end of that pipe does all of the work.
I'd rather wait on the entire process to finish so I know there were no
errors in the operation before I report the job done. Oh well, it works
just fine both ways. Good job!
for me, the trick is dealing with the fact that input may arrive on the
pipe at any time- including three notifications within the space of a
second. i know that (for my purposes) if an "add_domain xyz" message
arrives, for example, that i can wait 10 seconds before doing anything
(to give the vpopmail program time to finish and send any other
messages), and that any "add_mailbox [EMAIL PROTECTED]" or "mod_user
[EMAIL PROTECTED]" messages which arrive less than 5 seconds after i'm
done can be safely ignored.
It seems to me it is much easier to eliminate the noise at the source.
if the "onchange" script needs to know whether the user's request
affected a real or alias domain, simply look to see if there IS another
domain listed afterward- if so, the first one was an alias and the
second one is the real domain that the alias pointed to.
is this something that needs to be in there? if so, i'll write it in.
I don't see any value in reporting a delete operation after the fact,
other than to log it. On the other hand it might be a good idea to move
the script before the delete. That would give you a chance to take a
snapshot of the resource usage right before delete, or maybe make a backup.
I do think it is a good idea to name the parent domain if you delete an
alias domain, even if I don't know how someone would use it today. If
nothing else it will make my log entries look nicer.
If you've already got it worked out, go ahead and send me a patch. If
not you've described it well enough, it will be easy enough to do.
Why is this not add_valias, del_valias? (to make it the same as the
user/domain hooks) ?
I don't know. John?
the idea was that the names were are all the same as vpopmaild
commands. however, these functions don't exist in vpopmaild, so i used
the names of the actual functions within the vpopmail source code.
Sounds reasonable to me. I believe the reason they don't appear in the
daemon yet is because the cdb back end doesn't support them. It gets
worse, the way a cdb file and a database handle the data are quite
different and we need to add an order field to the database to make it
able to store entries in a fixed order and add functions to the cdb back
end to support the valias calls. someday...
would it be better to use the vpopmail function names for all of the
notifications, so that they are all consistent? if so, now is the time
to make the decision, since nobody (as far as i know) has written any
onchange scripts which would look for specific strings.
I don't really care. Robin - what do you think the names should be?
As far as I'm concerned, all I need is a complete list in front of me
when I sit down to write the script.
Rick -- KD7VKZ