Hi,
If you're on the system, depending on your trigger and privledges, you
might be able to execute a simple find command against a user's mail
files/folders (If you're asking on the courier list, I'll assume you're
using maildirs, which makes this easy). If you can log in to the imap
server as the user, you could call a script to log in to imap and get the
status of everything.
Not fast enough, and this needs to be based around a network, not requiring local disk access. the maildirs are on an NFS mount, which is not the speediest FS in the world, especially when you have 160,000 users & homepages, etc all at once! I did not design it, but I do have to live with it.
I'm not sure what you mean by 'realtime notification'. http is a pull, as
opposed to push, protocol. I.e., you can have a user autorefreshing a
document that lists his waiting mail, and the document gets updated at
every new mail. You can't have the browser autoreload the document on a
signal from the server, however. Of course, something with java or
javascript might help too.
This is true if the HTTP is between a user and a server. However, we are using it to notify the remote application server of new mails. Consequently, we are posting a query, so whilst we are 'pulling' a response, we are 'pushing' the data to generate the response.
Do you want to rely on the mail daemon to do this or do you want to search
the maildirs yourself? This would be a simple command/series of commands
to the imap server, or a find function.
Without the remote application being aware that any new mail has arrived (and it's developers are not prepared to constantly check for updates, nor do I want them automating frequent logins for many users), and without the user being logged in, we have to do it from the inbound transport. I am using maildrop, as this scales at thge current level, and beyond. It is also a lot more simple than writing a sendmail milter for the job, and gets done after delivery is completed.
If you are only concerned with providing notification when new mail
arrives, then all you need is that trigger. You should be able to write a
script that will run whenever new mail arrives and collect all the relevant
counts for that user.
'Tis already done, thanks to the folks at w3c for the libraries ;-) scripts do not scale to the projected userbase, but of course the projected and the real are very different things. So currently it is a script (speed of implementation, etc), primed for conversion to C if required.
If you want to provide notification on any action
(mark read/store/etc...) then you'll need something more custom.
This is true, and what I do not want to do. I have to finish this system, and leave it ready for anyone to support. The last thing I want to do is invent some custom patches for these things. I have already had to implement some aqncient patches against the latest courier IMAP because the web mail authors forgot to allow for 'NAMESPACE'. The patches, incidentally, are also for the netscape -1 bug, which Sam hates, and I agree with him. Unfortunately about two years ago (I seem to keep using that word ;-)), someone saw fit to distribute Netscape as the browser of choice for the platform in question.
Well, there are a few more details you would need to provide to be helpful.
1) Will this project always be with maildirs?
Yes, but that is irrelevant, since the application will always be on a remote, and untrusted host.
2) When you say 'realtime notification', what are you going for? Are you
trying to update a user's webpage with all his current mail stats? Are you
trying to pop a box up on the user's screen? Is the user expected to probe
for the new mail periodically, or is the user expected to run a listening
client that responds to messages from a server?
It is not for the user (although the end result is). This is a remote application in a (mobile) telco environment. Essentially, this is the last case you describe. The remote application will always be listening as it is a HA cluster behind at least one firewall.
3) Do you want 'realtime notification' of incoming mail, or of all mailbox
changes?
Incoming mail is handled at the moment. I can improve that using 'find' etc that other people have suggested, although I have not done this, since it's load on the FS will not be acceptable when the userbase grows. Ideally I would like to split the users for this app on to their own system, but that means money ;-)
I'm not sure what else to ask, but without being a little more specific,
I'm afraid its kind of hard to give you a direction.
I was hoping for opinions. And that is what I am getting, so I am a happy camper. Sorry for not supplying more info. The requirements of the telco applications, and developers are quite surprising, from an internet perspective. We are all used to waiting up to 30 seconds for a page to be displayed. However, how long would you wait to find out how many voicemails you have when you are using a mobile? People have different expectations from different terminals, and the mobile handset is now an internet terminal. Regrettably, the users do not seem to see it quite like that, and still expect real fast, and correct responses.
Ho Hum.
-JG
