|
|
|
|
-- |
|
|
|
|
|
-- Module: $Header$
|
|
|
|
|
--
|
|
|
|
|
-- Maintainer: info@jonkri.com
|
|
|
|
|
-- Stability: unstable
|
|
|
|
|
-- Portability: portable
|
|
|
|
|
--
|
|
|
|
|
-- The Extensible Messaging and Presence Protocol (XMPP) is an open technology
|
|
|
|
|
-- for near-real-time communication, which powers a wide range of applications
|
|
|
|
|
-- including instant messaging, presence, multi-party chat, voice and video
|
|
|
|
|
-- calls, collaboration, lightweight middleware, content syndication, and
|
|
|
|
|
-- generalized routing of XML data. XMPP provides a technology for the
|
|
|
|
|
-- asynchronous, end-to-end exchange of structured data by means of direct,
|
|
|
|
|
-- persistent XML streams among a distributed network of globally addressable,
|
|
|
|
|
-- presence-aware clients and servers.
|
|
|
|
|
--
|
|
|
|
|
-- Pontarius XMPP is an XMPP client library, implementing the core capabilities
|
|
|
|
|
-- of XMPP (RFC 6120): setup and teardown of XML streams, channel encryption,
|
|
|
|
|
-- authentication, error handling, and communication primitives for messaging.
|
|
|
|
|
--
|
|
|
|
|
-- For low-level access to Pontarius XMPP, see the "Network.Xmpp.Connection"
|
|
|
|
|
-- module.
|
|
|
|
|
|
|
|
|
|
{-# LANGUAGE NoMonomorphismRestriction, OverloadedStrings #-}
|
|
|
|
|
|
|
|
|
|
module Network.Xmpp
|
|
|
|
|
( -- * Session management
|
|
|
|
|
Session
|
|
|
|
|
, session
|
|
|
|
|
-- TODO: Close session, etc.
|
|
|
|
|
-- ** Authentication handlers
|
|
|
|
|
, scramSha1
|
|
|
|
|
, plain
|
|
|
|
|
, digestMd5
|
|
|
|
|
-- * Addressing
|
|
|
|
|
-- | A JID (historically: Jabber ID) is XMPPs native format
|
|
|
|
|
-- for addressing entities in the network. It is somewhat similar to an e-mail
|
|
|
|
|
-- address, but contains three parts instead of two.
|
|
|
|
|
, Jid(..)
|
|
|
|
|
, isBare
|
|
|
|
|
, isFull
|
|
|
|
|
-- * Stanzas
|
|
|
|
|
-- | The basic protocol data unit in XMPP is the XML stanza. The stanza is
|
|
|
|
|
-- essentially a fragment of XML that is sent over a stream. @Stanzas@ come in
|
|
|
|
|
-- 3 flavors:
|
|
|
|
|
--
|
|
|
|
|
-- * /Message/, for traditional push-style message passing between peers
|
|
|
|
|
--
|
|
|
|
|
-- * /Presence/, for communicating status updates
|
|
|
|
|
--
|
|
|
|
|
-- * /Info/\//Query/ (or /IQ/), for request-response semantics communication
|
|
|
|
|
--
|
|
|
|
|
-- All stanza types have the following attributes in common:
|
|
|
|
|
--
|
|
|
|
|
-- * The /id/ attribute is used by the originating entity to track any
|
|
|
|
|
-- response or error stanza that it might receive in relation to the
|
|
|
|
|
-- generated stanza from another entity (such as an intermediate server or
|
|
|
|
|
-- the intended recipient). It is up to the originating entity whether the
|
|
|
|
|
-- value of the 'id' attribute is unique only within its current stream or
|
|
|
|
|
-- unique globally.
|
|
|
|
|
--
|
|
|
|
|
-- * The /from/ attribute specifies the JID of the sender.
|
|
|
|
|
--
|
|
|
|
|
-- * The /to/ attribute specifies the JID of the intended recipient for the
|
|
|
|
|
-- stanza.
|
|
|
|
|
--
|
|
|
|
|
-- * The /type/ attribute specifies the purpose or context of the message,
|
|
|
|
|
-- presence, or IQ stanza. The particular allowable values for the 'type'
|
|
|
|
|
-- attribute vary depending on whether the stanza is a message, presence,
|
|
|
|
|
-- or IQ stanza.
|
|
|
|
|
|
|
|
|
|
-- ** Messages
|
|
|
|
|
-- | The /message/ stanza is a /push/ mechanism whereby one entity
|
|
|
|
|
-- pushes information to another entity, similar to the communications that
|
|
|
|
|
-- occur in a system such as email. It is not to be confused with
|
|
|
|
|
-- /instant messaging/ which is handled in the 'Network.Xmpp.IM' module
|
|
|
|
|
, Message(..)
|
|
|
|
|
, MessageError(..)
|
|
|
|
|
, MessageType(..)
|
|
|
|
|
-- *** Creating
|
|
|
|
|
, answerMessage
|
|
|
|
|
-- *** Sending
|
|
|
|
|
, sendMessage
|
|
|
|
|
-- *** Receiving
|
|
|
|
|
, pullMessage
|
|
|
|
|
, getMessage
|
|
|
|
|
, waitForMessage
|
|
|
|
|
, waitForMessageError
|
|
|
|
|
, filterMessages
|
|
|
|
|
-- ** Presence
|
|
|
|
|
-- | XMPP includes the ability for an entity to advertise its network
|
|
|
|
|
-- availability, or "presence", to other entities. In XMPP, this availability
|
|
|
|
|
-- for communication is signaled end-to-end by means of a dedicated
|
|
|
|
|
-- communication primitive: the presence stanza.
|
|
|
|
|
, Presence(..)
|
|
|
|
|
, PresenceType(..)
|
|
|
|
|
, PresenceError(..)
|
|
|
|
|
-- *** Creating
|
|
|
|
|
, module Network.Xmpp.Presence
|
|
|
|
|
-- *** Sending
|
|
|
|
|
-- | Sends a presence stanza. In general, the presence stanza should have no
|
|
|
|
|
-- 'to' attribute, in which case the server to which the client is connected
|
|
|
|
|
-- will broadcast that stanza to all subscribed entities. However, a
|
|
|
|
|
-- publishing client may also send a presence stanza with a 'to' attribute, in
|
|
|
|
|
-- which case the server will route or deliver that stanza to the intended
|
|
|
|
|
-- recipient.
|
|
|
|
|
, sendPresence
|
|
|
|
|
-- *** Receiving
|
|
|
|
|
, pullPresence
|
|
|
|
|
, waitForPresence
|
|
|
|
|
-- ** IQ
|
|
|
|
|
-- | Info\/Query, or IQ, is a /request-response/ mechanism, similar in some
|
|
|
|
|
-- ways to the Hypertext Transfer Protocol @HTTP@. The semantics of IQ enable
|
|
|
|
|
-- an entity to make a request of, and receive a response from, another
|
|
|
|
|
-- entity. The data content and precise semantics of the request and response
|
|
|
|
|
-- is defined by the schema or other structural definition associated with the
|
|
|
|
|
-- XML namespace that qualifies the direct child element of the IQ element. IQ
|
|
|
|
|
-- interactions follow a common pattern of structured data exchange such as
|
|
|
|
|
-- get\/result or set\/result (although an error can be returned in reply to a
|
|
|
|
|
-- request if appropriate)
|
|
|
|
|
--
|
|
|
|
|
-- <http://xmpp.org/rfcs/rfc6120.html#stanzas-semantics-iq>
|
|
|
|
|
, IQRequest(..)
|
|
|
|
|
, IQRequestTicket
|
|
|
|
|
, iqRequestBody
|
|
|
|
|
, IQRequestType(..)
|
|
|
|
|
, IQResult(..)
|
|
|
|
|
, IQError(..)
|
|
|
|
|
, IQResponse(..)
|
|
|
|
|
, sendIQ
|
|
|
|
|
, sendIQ'
|
|
|
|
|
, answerIQ
|
|
|
|
|
, listenIQChan
|
|
|
|
|
, iqRequestPayload
|
|
|
|
|
, iqResultPayload
|
|
|
|
|
-- * Threads
|
|
|
|
|
, dupSession
|
|
|
|
|
-- * Miscellaneous
|
|
|
|
|
, LangTag(..)
|
|
|
|
|
, exampleParams
|
|
|
|
|
, PortID(..)
|
Tweak failure approach
I'm assuming and defining the following:
1. XMPP failures (which can occur at the TCP, TLS, and XML/XMPP
layers (as a stream error or forbidden input)) are fatal; they will
distrupt the XMPP session.
2. All fatal failures should be thrown (or similar) by `session', or
any other function that might produce them.
3. Authentication failures that are not "XMPP failures" are not fatal.
They do not necessarily terminate the stream. For example, the
developer should be able to make another authentication attempt.
The `Session' object returned by `session' might be useful even if
the authentication fails.
4. We can (and should) use one single data type for fatal failures.
(Previously, both StreamFailure and TlsFailure was used.)
5. We can catch and rethrow/wrap IO exceptions in the context of the
Pontarius XMPP error system that we decide to use, making the error
system more intuitive, Haskell-like, and more straight-forward to
implement. Calling `error' may only be done in the case of a
program error (a bug).
6. A logging system will remove the need for many of the error types.
Only exceptions that seem likely to affect the flow of client
applications should be defined.
7. The authentication functions are prone to fatal XMPP failures in
addition to non-fatal authentication conditions. (Previously,
`AuthStreamFailure' was used to wrap these errors.)
I'm hereby suggesting (and implementing) the following:
`StreamFailure' and `TlsFailure' should be joined into `XmppFailure'.
`pullStanza' and the other Connection functions used to throw
`IOException', `StreamFailure' and `TlsFailure' exceptions. With this
patch, they have been converted to `StateT Connection IO (Either
XmppFailure a)' computations. They also catch (some) IOException
errors and wrap them in the new `XmppIOException' constructor.
`newSession' is now `IO (Either XmppFailure Session)' as well (being
capable of throwing IO exceptions).
Whether or not to continue to a) wrap `XmppFailure' failures in an
`AuthStreamFailure' equivalent, or, b) treat the authentication
functions just like the other functions that may result in failure
(Either XmppFailure a), depends on how Network.Xmpp.Connection.auth
will be used. Since the latter will make `auth' more consistent, as
well as remove the need for a wrapped (and special-case) "AuthFailure"
type, I have decided to give the "b" approach a try. (The drawback
being, of course, that authentication errors can not be accessed
through the use of ErrorT. Whether or not this might be a problem, I
don't really know at this point.) As the SASL code (and SaslM)
depended on `AuthStreamFailure', it remains for internal use, at least
for the time-being. `session' is now an ErrorT computation as well.
Some functions have been updated as hacks, but this will be changed if
we decide to move forward with this approach.
13 years ago
|
|
|
, XmppFailure(..)
|
|
|
|
|
, StreamErrorInfo(..)
|
|
|
|
|
, StreamErrorCondition(..)
|
Tweak failure approach
I'm assuming and defining the following:
1. XMPP failures (which can occur at the TCP, TLS, and XML/XMPP
layers (as a stream error or forbidden input)) are fatal; they will
distrupt the XMPP session.
2. All fatal failures should be thrown (or similar) by `session', or
any other function that might produce them.
3. Authentication failures that are not "XMPP failures" are not fatal.
They do not necessarily terminate the stream. For example, the
developer should be able to make another authentication attempt.
The `Session' object returned by `session' might be useful even if
the authentication fails.
4. We can (and should) use one single data type for fatal failures.
(Previously, both StreamFailure and TlsFailure was used.)
5. We can catch and rethrow/wrap IO exceptions in the context of the
Pontarius XMPP error system that we decide to use, making the error
system more intuitive, Haskell-like, and more straight-forward to
implement. Calling `error' may only be done in the case of a
program error (a bug).
6. A logging system will remove the need for many of the error types.
Only exceptions that seem likely to affect the flow of client
applications should be defined.
7. The authentication functions are prone to fatal XMPP failures in
addition to non-fatal authentication conditions. (Previously,
`AuthStreamFailure' was used to wrap these errors.)
I'm hereby suggesting (and implementing) the following:
`StreamFailure' and `TlsFailure' should be joined into `XmppFailure'.
`pullStanza' and the other Connection functions used to throw
`IOException', `StreamFailure' and `TlsFailure' exceptions. With this
patch, they have been converted to `StateT Connection IO (Either
XmppFailure a)' computations. They also catch (some) IOException
errors and wrap them in the new `XmppIOException' constructor.
`newSession' is now `IO (Either XmppFailure Session)' as well (being
capable of throwing IO exceptions).
Whether or not to continue to a) wrap `XmppFailure' failures in an
`AuthStreamFailure' equivalent, or, b) treat the authentication
functions just like the other functions that may result in failure
(Either XmppFailure a), depends on how Network.Xmpp.Connection.auth
will be used. Since the latter will make `auth' more consistent, as
well as remove the need for a wrapped (and special-case) "AuthFailure"
type, I have decided to give the "b" approach a try. (The drawback
being, of course, that authentication errors can not be accessed
through the use of ErrorT. Whether or not this might be a problem, I
don't really know at this point.) As the SASL code (and SaslM)
depended on `AuthStreamFailure', it remains for internal use, at least
for the time-being. `session' is now an ErrorT computation as well.
Some functions have been updated as hacks, but this will be changed if
we decide to move forward with this approach.
13 years ago
|
|
|
, AuthFailure( AuthXmlFailure -- Does not export AuthStreamFailure
|
|
|
|
|
, AuthNoAcceptableMechanism
|
|
|
|
|
, AuthChallengeFailure
|
|
|
|
|
, AuthNoConnection
|
|
|
|
|
, AuthFailure
|
|
|
|
|
, AuthSaslFailure
|
|
|
|
|
, AuthStringPrepFailure )
|
|
|
|
|
|
|
|
|
|
) where
|
|
|
|
|
|
|
|
|
|
import Data.XML.Types (Element)
|
|
|
|
|
|
|
|
|
|
import Network
|
|
|
|
|
import Network.Xmpp.Bind
|
|
|
|
|
import Network.Xmpp.Concurrent
|
|
|
|
|
import Network.Xmpp.Concurrent.Types
|
|
|
|
|
import Network.Xmpp.Connection_
|
|
|
|
|
import Network.Xmpp.Marshal
|
|
|
|
|
import Network.Xmpp.Message
|
|
|
|
|
import Network.Xmpp.Presence
|
|
|
|
|
import Network.Xmpp.Sasl
|
|
|
|
|
import Network.Xmpp.Sasl.Types
|
|
|
|
|
import Network.Xmpp.Session
|
|
|
|
|
import Network.Xmpp.Stream
|
|
|
|
|
import Network.Xmpp.Tls
|
|
|
|
|
import Network.Xmpp.Types
|