OFFLINE DELIVERY OF MESSAGES EJABBERD OFFLINE
In addition, if the user authenticates and provides presence for another resource while the first (non-flood) resource still has an active session, the server MUST NOT flood the second resource with the offline message queue. However, once the user sends presence, the user's server MUST deliver in-session messages as usual this document applies to offline messages only.
OFFLINE DELIVERY OF MESSAGES EJABBERD FREE
Thus the user is now free to send initial presence (if desired) and to engage in normal IM activities while continuing to read through offline messages. Upon receiving a service discovery request addressed to a node of "" (either a disco#info request as in this use case or a disco#items request as in the next use case), the server MUST NOT send a flood of offline messages if the user subsequently sends initial presence to the server during this session. Server Returns Information About Offline Message Node, Including Number of Messages ¶ If the server supports retrieval of the number of messages, it MUST include Service Discovery Extensions (XEP-0128) data specifying the number of messages: Example 4. User Requests Information About Offline Message Node ¶ In order to determine the number of messages in the offline message queue, the user sends a disco#info request without a 'to' address (i.e., implicitly to the user himself) and with the disco node specified as '': Example 3.
Such a feature would be helpful in Jabber/XMPP as well, especially if the client is constrained with regard to storage capacity or available bandwidth. RFC 1939 includes a feature (the "STAT" command) that enables a user to determine how many messages are waiting to be retrieved (without retrieving all of the headers).
Client determines server support for this protocol.In particular, such a protocol should support the following use cases: And it would provide for seamless integration with existing web-based email clients. It would enable the vacationer to read and delete their messages one at a time, minimizing the possibility of losing all correspondence. This would enable the wireless user to view header information for all offline messages and select only those from their boss and important clients for viewing. What is needed is a flexible semantic for offline message handling, similar to POP3 in the email world (see RFC 1939 ). With offline retrieval semantics so vastly different between the two, this is quite difficult.
Several large portals are currently trying to blur the distinction between IM and email - providing both through one web interface. It can be difficult to integrate with web-based email clients, which is undesirable for some portals. Should their client crash, they have lost all communication that occurred while they were away. Unlucky, however, is this user who then logs onto their Jabber server and is bombarded by hundreds of instant messages, possibly in scores of popup dialogs, simultaneously. Many individuals upon returning to work from a weeklong vacation spend the first few hours wading through the dozens, even hundreds, of emails that they received during their absence. It can be overwhelming, which is undesirable for the vacationer or heavy user. This simplification has the following deficiencies: The current means of retrieving one's offline messages is simple: one sends available presence to the server and, as a consequence, the server sends a one-time "flood" of all the messages that have been stored while one was offline. Such messages are commonly called "offline messages". Although not required to do so by XMPP Core and XMPP IM, many existing Jabber/XMPP instant messaging servers will store messages received while a user is offline and deliver them when the user is next online.
0 kommentar(er)
