I haven't followed this entire discussion... but wouldn't the following work ???
Run some tool/script from the users .courier file (it gets processed with every new mail) In that script/.courier file make a call to the http application server with your required data. Just my $0.02 Mark On Thu, 2002-03-14 at 12:38, Griffiths, Jon wrote: > 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 _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
