Hi Jeremy,
Sorry I've not been in touch - been kinda busy trying to build this thing.
It's currently "very alpha".
There are four files attached. notify_socket.c, server-core.pl, imapd.conf
and notify.conf
The imapd.conf and notify.conf files contain config information about
servers & ports, as well as the security key which is used for a very basic
level of authentication. They use the same variable names, so they could
actually be the same file. They've been implemented seperately so that the
server process can exist on a different machine to the IMAP server.
There's a small stream based protocol included in this, for authenticating
the client (imapd) to the server. This allows for the other facilities that
I want to do with the notify server process.
The notify_key has to be the same in imapd.conf and notify.conf. It's
crypt()-ed, and used to make sure that the notification message is coming
from an expected client.
The code in notify() will fail silently if there's any problem at all with
the communication. This system is not designed to have any level of
resilience at present.
The server-code.pl file basically just dumps the data into a text file at
the moment. The actual notification function can be included there instead.
Any queries, commments or sarcastic rejoinders would be appreciated.
Steve
> I'm also looking at writing a notify handler (in my case, to
> notify through
> SMS). I think that the best way to do this is to write a generic notify
> handler that simply passes the user@domain, subject, and first n chars of
> the body to a unix socket. That way anyone can write their own
> little daemon
> in their preferred language to actually implement the notification.
server-core.pl
notify.conf
notify_socket.c
imapd.conf
