For general information... as I spent a lot of time tracking down the
library I liked and wanted to be sure it was getting the attention it
deserved.

I am a long-term users of Jabber-net for our xmpp library but were
growing frustrated with the lack of Compact Framework support.  I found
the jabber-net codebase too difficult to work with, just a clash in
programming style... so I went looking for alternatives.

I recently discovered a library named Piorun.Xmpp with a very clean
codebase and a flexible license (MIT X11, similar to BSD license).  It
was available in the experimental .NET programming language Boo but we
recently completed a C# conversion and now both languages are available
for Piorun.Xmpp.

The code is available here:  http://piorun.sztorm.net/trac/

Based on my own experience, I would consider Piorun.Xmpp a good
alternative to AgsXMPP (good cross-framework support, but restrictive
license) and Jabber-net libraries (good license, but no support of
Compact Framework).

There is a mailing list for developers if you want to help contribute.
I will be subscribed if you need any assistance with the library.  Now
that we have a C# version working, I am still doing some work on the
Compact Framework 1.x compatibility, but it is only minor changes.

Hope this is of use to someone.

  Stephen Gutknecht


Extra Keywordz: csharp xmpp jabbernet jabber.net jabber.org GTalk
Google talk protocol xml instant messaging im vb.net mono instant
message CF

<nikic***@gmail.com> wrote
[.Net Frameworks for RFC 3920 and RFC 3921 (aka: XMPP or Jabber)]

There are a large number of frameworks that support these two RFC's. I spend
quite a bit of time working with the protocol, and have a pretty good grasp
of things XMPP. I've personally implemented RFC 3920 and RFC 3921 on both
the Client and Server side, as well as a huge number of Extensions (called
JEPS). I should state, I work for a company that builds commercial XMPP
products in .Net, including an SDK.

In my experience, the fragmentation in the SDK area for XMPP is huge. The
barrier to entry for writing an open-source SDK is very low, and as a result
it's been done a number times. Not as often as a home-grown SMTP server, but
probably close and with about the same results.

This means there are dozens of very poorly written, bug ridden, and
feature-incomplete packages out there. Many of these SDK's don't support
required features - such as SASL or StringPrep. Many don't support highly
desirable features, such as Stream Compression or SSPI Authentication. Then
there are the 100+ JEPS you would look for to have supported in your SDK,
and most of them fail here too.

[Warning: Shameless plug ahead!]

As far as I know there's only one framework that support everything, runs on
desktops, mobile devices (.Net Compact Framework), and on Linux (via Mono)
and has commercial grade support, features, and quality. That SDK is the one
I work on as an architect and developer - the SoapBox Framework. It's also
highly scalable, as the SoapBox Server is built on top of it and that server
has scaled to more than 250,000 simultanious users on IA64 hardware. The
SoapBox Framework has 1000+ unit tests, is completly Object Oriented, been
performance and memory pressure tuned, offers dozens of custom performance
counters, comes with merge moduels for easy application deployment, and
pretty good documentation.

Async Sockets and IOCPS
Immutable Classes
Adding a Section In Configuration File
Converting 1.1 webapp to v2
Dealing with Timezones