> > PS^2; I would also like some input for those of us that enjoy playing, > researching, testing and documenting ;-) > sure !
I've pushed a draft in our github repository : https://github.com/worldline-messaging/cyrus-imapd branch msgevent. Most of the commit is viewable here : https://github.com/worldline-messaging/cyrus-imapd/commit/2ab15d71bbd682b25708bb50082078f6f786b353 People can play with it, I made some bunchs of tests without any issue. below the available options : - eventnotifier: enable message store event notification with the Notifyd(8) method. just set eventnotifier: log in your imapd.conf to enable notification to syslog - event_exclude_flags: don't notify FlagsSet/FLagsClear/MessageTrash/MessageRead notification for given flag(s) or remove the given flag(s) from the flagNames list in case of many flags - event_exclude_folders: not yet supported. Disable notification if event occur on a folder in the list (ie Spam folder) - event_extra_params (flagnames, messages, timestamp, uidnext, vnd.cmu.midset, vnd.cmu.newMessages) a list of extra parameters to add to notifications that are not mandatory in the RFC. - event_groups (message, flags, mailbox, access) : not yet supported. Enable notification for these groups of events as suggested in the RFC - event_notifspam: not yet supported. Disable event notification for email rated as spam. Needs a standard way to identify a message marked as spam ($Junk flag ?) - event_timestamp_format (iso8601, epoch) : set the format of the timestamp parameter. Both formats print fraction of second for easier notification ordering To discuss a little about the code. I first thought to collocate the notification code to the auditlog trace code or at a low level in the code on any mailbox change. But for both choices we lose the context of the change (send 3 notifications per mailbox rename, may send several notifications in a mailboxe hierarchy, send notification for mailbox create on the cyrus slave, ...) and become not RFC compliant. In our current code that runs in cyrus 2.3, the event_state structure is define in the mailbox structure. But I decided to get out event_state in order to respect the separation of concern. here is my todo list: - the ability to turn on and off groups of related events - the ability to turn off notification that occur on a given list of folder (may depend on SPECIAL-USE ?) - the ability to turn off notification for SPAM - handle event notification in cyrus admin tools (ipurge, ...) - format the IMAP URL with the external representation of the mailbox - provide JSON as default format and key/value pairs format in contrib/ - provide a stomp or AMQP connector to notifyd - some code improvements (better event_state allocation, handle them in a list, choose between EVENT_PENDING/EVENT_ABORTING states and mboxevent_notify/mboxevent_abort functions, - write documentation :) I'm on holiday for two weeks. But feel free to make any comment, suggestion about the design of the code, new features, the name of function/structure/file/option or whatever. Regards, Sébastien You may have noticed that Coloos Julien, Olivier Roland, Christophe Zbierski and I are all members of the same team at Atos Worldline
