Brennan,
PHP is essentially a CGI scripting language, designed to process HTTP
requests and generate responses. Using it to implement some kind of
persistent server would be at odds with this design.
If you want a full-time server with durable in-memory state for each
client, a JSP/Servlet architecture would be more appropriate. There was
a webmail project called JWebMail <http://jwebmail.sourceforge.net/>
that attempted to do this a few years ago, but I don't think it's been
maintained. I started playing with it before I discovered RoundCube, but
it was far enough out of date that it would have been a significant
effort to pick it up and run with it.
RoundCube already caches messages in MySQL (or another relational
database provider) to avoid round trips to the IMAP server. The
assumption there is that the MySQL server is located in close proximity
with the web server, and therefore has lower communication latency than
the (possibly remote) IMAP server.
Finally, attempting to examine the actual mbox or maildir storage from
the PHP script would be counterproductive. The raison d'être of the IMAP
server is to encapsulate the details of the mail storage and retrieval.
Striving for faster performance is an excellent pursuit, but deviating
too far from the fundamental architecture of the application has its own
cost...
-Eric
Brennan Stehling wrote:
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.
--
*Eric Stadtherr*
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
