Yes, it is not exactly a straightforward solution. I would like a more modular mail system which would give us more hooks to handle incoming mail. I know you can create milters, etc, but those are not a trivial thing to build. I once created extensions to the Apache web server with mod_perl which was really quite easy and I was able to make Apache do something the available extensions could not do alone. (SSL secured reverse proxy with LDAP lookup)
There is the James mail server which was created with Java which I believe had plans for plugins. But I cannot really run Java on my FreeBSD 5.x server.
Is there a modular IMAP server which has hooks for languages like Perl, Python or Ruby?
Brennan
On 2/7/07, till klimpong@gmail.com wrote:
I guess you can use just about anything to implement that additional performance layer. Whatever floats your boat.
On 2/7/07, Brennan Stehling brennan@offwhite.net wrote:
Interesting. I suppose I could use a Perl script which sits and listens for notifications and loads data into the MySQL database for me. I was hoping to avoid using a server-side language besides PHP but if PHP is not going to work as a daemon process then Perl seems like the right alternative.
Brennan
On 2/7/07, Mathieu Lecarme mathieu@garambrogne.net wrote:
Brennan Stehling a écrit :
I am not terribly familiar with the lastest in PHP.
One concept I am considering is a way to keep the state current on the server for the webmail user. Currently the PHP code is only run when there is a request, but it would be helpful to have something running on the server continually which can respond to events in real-time.
Here is the idea.
A user logs into the system and that updates a timestamp for their date of last activity. Each time the RC webmail client looks for new messages it would update this timestamp. The service running on the server would be away of active sessions and watch their related IMAP accounts for new activity.
When a new message does arrive it can pull the summary data and place it into the MySQL database so that when the webmail client looks for an update it can just query the database and not MySQL.
And when it does pull the updates from the server it will also just hit the database for the summary data and only use the IMAP server when pulling the full message.
Has anyone seen PHP run on the server-side continually as a service? How would we go about implementing that?
Also, what facilities would PHP have to monitor a directory of files for updates? Will it just have to poll the directories and files for the last update date? Since PHP is largely just meant for web applications I doubt it has a file system monitoring feature.
PHP is not a daemon, it's it secret weapon for managing memory leak and bad code. Every time a new PHP born, respond and die.
For file monitoring, there is FAM (File Alteration Monitor) http://fr2.php.net/manual/en/ref.fam.php
But it's out of scope, IMAP is an abstraction, you can't watch file modification, it's IMAP server business, not yours.
IMAP is pull centric, not push. If you wont to do stuff like that, Cyrus (the most complete IMAP implementation) use notifyd, wich send some UDP packet when a mail comes, you can listen UDP port in a php script (not a server one), with a loop and all server stuff wich can put data in MySQL for its brother, php web.
http://cyrusimap.web.cmu.edu/imapd/man/notifyd.8.html http://pwet.fr/man/linux/commandes/zephyr
M.
-- Brennan Stehling http://brennan.offwhite.net/blog/ http://www.smallsharptools.com/
-- Till Klampaeckel e: mailto:klimpong@gmail.com p: +491704018676 l: http://beta.plazes.com/whereis/till
Want to know what's up in Berlin?