Wolfram A. Kraushaar wrote:
Is it handled through database triggers.
If not, what is the meachnism used to inform the clients
about a new
message, deleted message or message state chage.
DBMail doesn't support IDLE [yet?]
dbmail-imapd would need an IPC/RPC interface to support IDLE
w
Geo Carncross wrote:
On Wed, 2005-03-30 at 22:21 +0200, Paul J Stevens wrote:
Geo Carncross wrote:
DBMail doesn't support IDLE [yet?]
I've added it to the TODO for 2.1.2 after reading the relevant rfc.
Clients that support IDLE also [tend to] support unsolicited updates to
the current
On Thu, 2005-03-31 at 09:19 +0200, Paul J Stevens wrote:
>
> Wolfram A. Kraushaar wrote:
> >>>Is it handled through database triggers.
> >>>If not, what is the meachnism used to inform the clients
> >>
> >>about a new
> >>
> >>>message, deleted message or message state chage.
> >>
> >>DBMail doe
On Thu, 2005-03-31 at 09:25 +0200, Paul J Stevens wrote:
> > Clients that support IDLE also [tend to] support unsolicited updates to
> > the current mailbox, which is just as good- and actually better if
> > SEARCH is cheap-enough.
>
> I'm not sure I understand what you mean by 'unsolicited updat
Geo Carncross wrote:
Be careful doing non-atomic things during signals. Since the signal will
likely have to write to a fifo anyway, it may be better to simply select
() on that fifo in the first-place...
SELECT mtime FROM dbmail_mailboxes WHERE mailbox_idnr='%llu';
seems pretty atomic to me.
On Thu, 2005-03-31 at 18:45 +0200, Paul J Stevens wrote:
> Geo Carncross wrote:
> > Be careful doing non-atomic things during signals. Since the signal will
> > likely have to write to a fifo anyway, it may be better to simply select
> > () on that fifo in the first-place...
>
> SELECT mtime FROM
