John Simpson wrote: > (re-arranging things so the sequence of my answers makes sense...) > > On 2006-04-15, at 2237, Rick Widmer wrote: >> John Simpson wrote: >>> 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. > > much easier to write an "onchange" script, yes... but less flexible. > > and while it may seem like "noise" to a human being, to a computer it's > just a sequence of messages. and unless the server itself is already > overloaded, the extra CPU load involved is minimal. > > besides, if we decide in the future to allow users the option to use > something other than "postmaster" for that function, then seperate > messages will be necessary and it would not be proper to assume that an > "add_domain" notification will always imply an "add_user [EMAIL PROTECTED]" > notification. > > i don't feel right giving up that flexibility. the flexibility is why i > wrote the "onchange" patch to run a script- my first idea was to have it > write to a named pipe, since that's what i'm actually doing on my own > server. i figured if i wrote it to call a shell script, and then had > that script write the data to the pipe, the fact that there's a shell > script in the middle would make it a lot easier for other people to > write their own "onchange" handlers (or to combine two of them if needed.) > > i can see collapsing multiple messages into a single invocation of the > "onchange" script if we follow that route, but i'm still not convinced > that we should do away with the multiple messages entirely- not even > with blocking the mod_user notification within add_user within > add_domain, because somebody in the future may decide that they want to > track quotas with the "onchange" mechanism for some reason. i don't > think it's right to arbitrarily lock them out of such a possibility, > especially when it's easy enough to write the "onchange" script so that > it's not an issue. > > robin? anybody else? thoughts about this?
I agree with John. Removing the multiple messages is a premature optimisation. Having thought about this some more, I think that a better approach would be to have both pre- and post- hooks for each action and to call a separate script for each hook. The benefit to this is that you would only call the hook if the script exists. So, by default, there would be no scripts so no hooks would be called. To create a hook, admin simply drops a script in VPOPMAILHOME/hooks/ (e.g. add_user_pre). > yeah, i've been complaining about the "fixed order" stuff for about four > years now. > > for those who don't know what we're talking about- if you think of a > ".qmail" file, it may have multiple lines in it. the first line might > run spamassassin, the second line might use "condredirect" to store the > message somewhere (or simply not deliver it) based on the score, and > then the third line would order everything else delivered to the normal > inbox folder. > > when aliases are stored in a SQL database, there is no field in the > database to hold what order the entries should be executed in. doing a > "SELECT * FROM valias" query might return these same three items in any > random order, because there is no "ORDER BY" clause in the query, > because there is no field by which to order the results. and if it > happens to return the steps in the wrong order, your filtering doesn't > work. > > what needs to happen is that some kind of sequence field needs to be > added to the table(s), and the alias-related functions need to be > re-written to properly work with these fields, as well as deal with > existing databases where there is no sequence value. we probably also > need a utility to retroactively "fix" any existing databases- for > single-item aliases, put an explicit 0 in the sequence field so it's no > longer NULL. for multi-item aliases, print out the alias and the lines, > so that the administrator can manually fill in the sequence field on > each record. Why not just store the whole .qmail as a multi-line text object? >>> 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. > > i hear ya. robin, or anybody else- any thoughts? i have no preference > either way- if nobody cares, i'm just going to leave it the way it is > right now. At the risk of repeating myself (this is about the third time I've typed this in the last few minutes!), I don't mind either as long as they're consistent, i.e. add_user or user_add but not both. R.
