XMPP[1] is a protocol for asynchronous communication via long-lived XML documents. It is most famous for underlying the Jabber and Wave protocols, but is also used for a variety of cases where security and extensibility are useful. My library, network-protocol-xmpp[2], is an implementation of most of RFC 3920 and a bit of RFC 3921. It supports opening client-to-server and component-to-server sessions, which is useful for implementing XMPP-based clients. This library's interface is very simple: clients may start a session with 'runClient' or 'runComponent', send and receive stanzas, and resume stored sessions. Later, I intend to add additional modules to support features such as MUC or file transmission, but for now I'd like to make sure the core library works. There's an example XMPP client, echo.hs[3], in the Darcs repository. Server-to-server sessions and accepting connection requests are not yet supported, so it's not usable as the foundation of an XMPP server yet. However, given that XMPP prefers to place features on the servers rather than clients, it's likely that writing an XMPP server in Haskell would take a *lot* of effort anyway. You're probably better off just using ejabberd or OpenFire. My thanks go to Stephan Maka, who let me know that this library actually has users, and who contributed most of the Component connection implementation. ---------- Additionally, I'm trying an experiment intended to break the gridlock of Haskell XML libraries. Currently, there are multiple options for XML handling (HXT, HaXml, libxml, tagsoup, xml, xml-basic) but each defines their own data types. This makes it very difficult to mix-and-match -- I can't easily use one library's parser with another's tree manipulation combinators. Simple use cases, such as using HXT for serializing, drag in dozens of dependencies on libraries like HTTP and QuickCheck. A library's poor data type definitions (such as HaXml's lack of support for namespaces) means that an entire set of potentially useful operations is unusable. And a library's choice propagates! In n-p-xmpp 0.2, which used HXT, clients were forced to figure out arrows before they could perform even rudimentary inspection of received stanzas. To fix this, I've created the xml-types[4] package. Its only dependency is the "text" library, and it defines full types for most XML structures[5]. My hope is that other libraries will replace their own types with these, so that (for example) I can parse events with libxml, manipulate them with HXT's arrow API, and write them back out using a custom serialiser without having to jump through type conversion hoops. It might take some time before any major XML libraries are transitioned to these types, but maybe in a year or two there'll be enough to be useful. [1] http://en.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol [2] http://hackage.haskell.org/package/network-protocol-xmpp [3] http://patch-tag.com/r/jmillikin/xmpp/snapshot/current/content/pretty/exampl... [4] http://hackage.haskell.org/package/xml-types [5] I haven't included types for inner entity declarations in DTDs, out of laziness, because does anybody actually *use* those?