電子メールの受信トレイを入力キューとして使用するデーモンアプリケーションに取り組んでいます。サーバーのオーバーヘッドを最小限に抑えて応答時間をできるだけ長くする必要があるため、電子メールの受信トレイをポーリングすることは問題外です。IMAPプロトコルは新着メールの通知を可能にするため、これはアプリケーションにとって理想的です。
ただし、Delphi / Indyアプリケーションにこのメカニズムを実装しようとすると、問題が発生しました。TIdIMAP4はうまく機能しますが（私の場合は関係のないUnicodeの問題は別として）、通知を実装する方法が見つかりませんでした。
これは単純なGIYFの問題であるはずですが、なんらかの理由で、オンラインで検索したときにIndyコンポーネントに関連する情報が見つかりません。
解決策または代替アプローチを深くいただければ幸いです。
編集：Indyは非同期の電子メール通知をサポートしていないように見えるので、delphiの無料コンポーネントがそれを可能にすることを誰もが知っていますか。
TIdIMAP4は、新しい電子メール通知などの非同期通知の受信をサポートしていません。そのためには、TIdIMAP4の実装を、TIdTelnetが使用するものと同様のマルチスレッドモデルに変更する必要がありますが、TIdIMAP4の現在のブロッキングコマンド/応答モデルのために、より複雑になります。今のところ、受信トレイを定期的にポーリングする必要があります。
アプリをクライアントではなくSMTPサーバーにしてみませんか。
これにより、新しいメールをプルする代わりに、メールがアプリに直接送信されるため、直接通知を受け取ることができます。
いくつかのフォールバックがあります。アプリがダウンした場合にメールがキューに入れられないという点ですが、msexchangeやpostfixなどをセットアップして非常にうまく機能させることができると確信しています。
Ok。これは代替ソリューションです。電子メールを使用する理由がないと仮定すると（たとえば、情報が電子メールを介して外部ソースから送信される場合）、入力キューを作成するためのはるかに簡単な方法としてデータベーステーブルをお勧めします。
定期的にデータベースをポーリングするだけです。これは、電子メールの受信トレイをポーリングするよりもはるかに高速であり、予想よりもはるかに高速です。データベースのポーリングは非常に高速であり、パフォーマンスにほとんど影響を与えることなく、データベーステーブルを1分間に数百回簡単にポーリングできます。
Qアイテムを格納するテーブルを作成し、タイムスタンプを格納できるフィールドを追加するか、このqアイテムが処理されたことを示すフラグを追加するだけで、次の未処理のアイテムをスタックから削除できます。
例：mssql
select Top 1 * from tbl_MyQ where AlreadyHandled = 0
mysql
select * from tbl_MyQ where AlreadyHandled = 0 Limit 1
それから
update tbl_MyQ Set AlreadyHandled = 1 where QueueID = #ItemIDRetrieved#
データベースは高速です。心配な場合はテストを実行してください。また、IMAPイベントや電子メールの受信トレイよりもはるかに複雑ではありません。
電子メールの受信トレイ（IMAP）がアーキテクチャの基本要件であり、使用可能なIMAPクライアントがない場合は、別の言語（C、C＃、さらにはJava）で記述された非同期通知を備えたIMAPクライアントを見つけて'を実装しようとします。新しいメッセージが到着したときにDelphiデーモンアプリをトリガーするプロキシまたはゲートウェイ。
Delphiデーモンは、単純なソケットベースのプロトコルまたはhttpを使用して、メッセージ（TIdHTTPServer、TIdTCPClient）を受信できます。
Indyの学習曲線が急である場合は、無料でオープンソースのArarat Synapse TCP / IPライブラリを使用してプロトタイプを作成できます。これは、Delphi 2009アプリで非常にうまく機能します（コンパイラが文字列/ansiについて文句を言うことを除いて）変換）。