1MAIL::ACCOUNT::UPDAT(3x)Cone: COnsole Newsreader And EMAIL::ACCOUNT::UPDAT(3x)
2
3
4

NAME

6       mail::account::updateNotify - Request notification of folder updates
7

SYNOPSIS

9       #include <libmail/mail.H>
10
11
12       class myCallback : public mail::callback {
13       public:
14           void success(std::string msg);
15           void fail(std::string msg);
16       };
17
18       mail::account *account;
19
20       account->updateNotify(bool enableDisable, myCallback &callback);
21

USAGE

23       If supported by the mail server, this function requests that the
24       application be notified immediately if another application makes any
25       changes to the currently open folder. This includes:
26
27       ·   New mail delivered to the folder.
28
29       ·   Existing messages removed from the folder.
30
31       ·   Changes to the messages´ flags.
32
33       These events are normally reported by invoking the newMessages,
34       messagesRemoved, and messageChanged method of the
35       mail::callback::folder object that was passed to
36       mail::folder::open(3x).
37
38       These callback function normally are not generated immediately after
39       the corresponding events occur. Changes to the folder´s contents are
40       usually checked only when the next request is processed; additionally
41       many mail servers do not even do that, and only check for changes when
42       the mail clients explicitly asks the server to check for new mail
43       (mail::account::checkNewMail(3x)) or to update the permanent message
44       status ( mail::account::removeMessages(3x) or
45       mail::account::updateFolderIndexInfo(3x)).
46
47       This method requests the server to notify the application immediately
48       when another application changes the folder (the enableDisable
49       parameter is true), or to stop notifying the application (enableDisable
50       is false).
51
52           Note
53           This method only works with IMAP mail accounts on IMAP servers that
54           support the IMAP IDLE extension, as described by RFC 2177[1]. This
55           method has no effect with IMAP servers that do not implement the
56           IDLE extension, or other mail accounts.
57
58           This method is also implemented for local mail in maildirs, on
59           systems running the SGI File Access Monitor[2]. This method has no
60           effect on mbox mail folders, or on systems without the FAM daemon.
61
62       The immediate update notification mode is enabled until it is
63       explicitly disabled. When the immediate update notification mode is in
64       effect with an IMAP IDLE-capable server, any other request silently
65       terminates the IDLE mode, performs the request, and reenters IDLE mode.
66
67       This method is a no-op if the account does not support the update
68       notification mode, and callback´s success method is quietly invoked,
69       without any further processing. When enableDisable is true, the success
70       method is invoked when the IMAP server acknowledges that it entered the
71       IDLE mode, or when monitoring begins on the currently open maildir
72       folder. When enableDisable is false, the success method is invoked when
73       the IMAP server acknowledges the completion of the IDLE command, and
74       immediate update notification mode stops (or after maildor folder
75       monitoring stops).
76
77           Note
78           When enableDisable is set to false, it is still possible that some
79           mail::callback::folder callback methods will be invoked before
80           success. This occurs when the server was in the process of
81           reporting folder changes just before the client requested the
82           termination of immediate update notification.
83

RETURN CODES

85       The application must wait until callback´s success or fail method is
86       invoked. The success method is invoked when this request is succesfully
87       processed. The fail method is invoked if this request cannot be
88       processed. The application must not destroy callback until either the
89       success or fail method is invoked.
90
91           Note
92           callback´s fail method may be invoked even after other callback
93           methods were invoked. This indicates that the request was partially
94           completed before the error was encountered.
95

SEE ALSO

97       mail::account::checkNewMail(3x), mail::account::removeMessages(3x),
98       mail::account::updateFolderIndexInfo(3x), RFC 2177[1].
99

NOTES

101        1. RFC 2177
102           http://www.rfc-editor.org/rfc/rfc2177.txt
103
104        2. File Access Monitor
105           http://oss.sgi.com/projects/fam/
106
107
108
109[FIXME: source]                   05/08/2010          MAIL::ACCOUNT::UPDAT(3x)
Impressum