> I take it from your comments below that a subsystem (POP3, SMTP etc) > would be responsible for doing it's own stats logging?
Yes, don't forget that the subsystems are seperately usable, you can leave out protocols you don't want, and activate those you do. You might want to turn off POP3 and NNTP and just use SMTP, or add IMAP. > Would this model cope with such things as collecting the number of > emails in a users account or counting the number of messages in the > spool? These actions would often be generated on a time interval, rather > than continously generated (I want to know how many emails an hour I > delivered, for example). I supposed this could be the job of a stats > timer that would gather such information and update the stats registry > as appropriate. If you did it right it would :-) perhaps you should have seperate stats logging into a stats repository by each subsystem "block" and a new block to collate those simple stats into sensible summary information, which, if you design your data well, could span more than one blocks stats, although I cannot see an immediate use for this. > The other thing that any implementor of the stats interface would need > to be aware of is the volume of data being stored. Such information > needs to be regularly written to disk, otherwise the VM will simply blow > up in your face. The Qmail system I worked on was chatty, but all it did > was write to disk based log files straight away, and leave any stats > analysis to other near-line programs. I would not want to see mail > processing hammered due to logging taking excessive CPU,memory or I/O. > Counters are fine in memory, but more heavy information (email size, to > , from etc) needs to written to disk. I might be belabouring the point > here, but there also needs to be someway of getting the information out > of James into a useful format. Of course, and James is well provided with examples of persistent storage, after all thats a big part of what it does, passing mail and account information into and out of several persistant storage repositories, many of which can be quickly change in their implementation by thanks to the intelligent use of Avalon's many parts (I'm not even going to say which bits, I get it wrong too often :) d. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
