views:

93

answers:

4

I am working on a deamon application that uses e-mail inbox as its input queue. Response times should be as high as possible with server overhead kept to minimum, so polling e-mail inbox is out of question. As IMAP protocol enables the notifications on new e-mails, this is ideal for the application.

However, I've run into troubles when I tried implementing this mechanism in my Delphi/Indy application. TIdIMAP4 works great (apart from some Unicode problems that are irrelevant in my case) but I couldn't find the way to implement notifications in it.

This should be a simple GIYF problem but for some to-me-unknown reason, I cannot find ANY relevant information on Indy components when searching online.

A solution or alternative approaches would be deeply appreciated.

Edit: Since Indy appearently does not support asynchronous e-mail notifications, does anybody know what free components for delphi would enable that.

A: 

Ok. This is an alternative solution. Assuming there is no reason you wish to use emails (eg your information is coming form an external source via email), then I would suggest a database table to be a much more straightforward way to create an input queue.

Simply poll the database on a regular basis. This would be much, much quicker than polling an email inbox, and much quicker than you think it will be. Polling a database is very fast and you could easily poll a database table several hundred times a minute with very little appreciable affect on performance.

Simply create a table to store your Q items and add an extra field that you can store a timestamp or flag that this q item has been handled, then you just take the next unhandled item off the stack

eg mssql

select Top 1 * from tbl_MyQ where AlreadyHandled = 0 

mysql

select  * from tbl_MyQ where AlreadyHandled = 0 Limit 1

then

update tbl_MyQ Set AlreadyHandled = 1 where QueueID = #ItemIDRetrieved#

Databases are fast, run a test if your worried. And they are much much less complicated than IMAP events and email inboxes.

Toby Allen
We've been considering that but since input comes from various human users in the form of e-mail in the first place, database would be an unnecessary middle step.
Tibor
There are databases that implements queues as well (Oracle does). They take care of concurrency (your code doesn't, two processes could get the same record before ones sets it handled). And there are database that let you fire events to clients (again, Oracle does) with no need of polling a table continuosly.Otherwise there are pure message queues.
ldsandon
+2  A: 

TIdIMAP4 does not support receiving asynchronous notifications, such as new email notifies. That would require changing TIdIMAP4's implementation to a multithreaded model similar to what TIdTelnet uses, but more complex because of TIdIMAP4's current blocking command/response model. For now, you must poll the inbox periodically.

Remy Lebeau - TeamB
Do you know any otther good Delphi IMAP client components?
Tibor
I do not, sorry.
Remy Lebeau - TeamB
+1  A: 

Why not make the app an smtp server, instead of client.

This way you have direct notification as the email is sent direct to your app, instead of pulling new email.

There are a few fallbacks, in that email won't queue if your app is down, although I'm sure that ms exchange, or postfix etc can be setup to work with it quite well.

MarkRobinson
A: 

If the email inbox (IMAP) is a basic requirement in your architecture and there are no IMAP clients available, I would try to find a IMAP client with asynchronous notification written in a different language (C, C# or even Java) to implement a 'proxy' or gateway which then will trigger your Delphi daemon app when new messages arrive.

The Delphi daemon could use a simple socket based protocol or http to receive the messages (TIdHTTPServer, TIdTCPClient).

If the learning curve of Indy is to steep, you could write a protoype with the Ararat Synapse TCP/IP library which is free and open source, it works very well in my Delphi 2009 apps (except that the compiler complains about some string/ansi conversions).

mjustin