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

NAME

8       mail::account::updateNotify - Request notification of folder updates
9

SYNOPSIS

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

USAGE

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

RETURN CODES

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

SEE ALSO

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

AUTHOR

103       Sam Varshavchik
104

NOTES

106        1. RFC 2177
107           http://www.rfc-editor.org/rfc/rfc2177.txt
108
109        2. File Access Monitor
110           http://oss.sgi.com/projects/fam/
111
112
113
114Cone©                             08/25/2016          MAIL::ACCOUNT::UPDAT(3x)
Impressum