ANNOUNCE: network-protocol-xmpp 0.3

[John Millikin]

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/examples/echo.hs
[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?