MSN-compatible custom smiley handling in Jabber

It's an ongoing university project run by me with the much appreciated help of Peter Saint André and others.

You can read about it here.

Twitter posting bot implementation

This is a fast-and-dirty hack to enable posting to twitter. It uses Smack, the java library OpenFire (formerly WildFire) and Spark are built upon, and I used the same IDE (IntelliJ IDEA) which is used by Jive Software to implement their (wonderfully clean-coded) software.

Basic "disadvantages":

• No bothering with config files (educational purposes) => account/password, admin hardcoded


• Also, since educational purposes - public domain! (you'd modify an existing source to learn jabber anyway)


• Uses apache's java HTTP client library - a simple auth to twitter and a POST


• User binds twitter account by sending a register <twitterusername> <twitterpassword> message to the bot.
  
• Doesn't save its state (bot stops => twitter account data lost)- could implement with Serializable markerinterface


• Doesn't use session-handling: logs into twitter every time; normally, twitter api would need to remember session cookies for each user/pass and trying to simply post the status variable, and if fails (with errorcode 403 presumably), relogin and store session cookies again


• No multithreading - if twitter is slow, the bot stops responding while doing HTTP query. Normally, at least two threads (one for the twitter api and one for the XMPP connection) should be used.


• No selective presence/multiple resources/etc - load balancing could be done with bots with same accounts but different resources and probably selective presence/invisibility

You can download java sourcecode here.

The needed libraries - which aren't in public domain(!) - are boundled too.

Jabber client example in KDE/QT

This is a small client I developed for educational purposes on top of KDE and gloox (for simplicity) in C++.

Basic ideas:

• Jabber data processing needs a loop and/or an event handler (depending on architecture). Most graphical systems will also need one, this can cause problems. In this example, we used QT's idle processing feature, which called a single cycle of Gloox's message processing. A kgloox wrapper class was written for this.


• In case writing a client application (not a bot or likesome), we need to connect conversations to windows. Most users feel comfortable that they have one window for each contact (or at least, each resource). Because of incoming messages, we'll need a mapping of contact -> window, and also a window->contact mapping. Although the second one could be stored in the window class itself in some environments, the first one will definitely need some window manager object. Some would argue that it's just a matter of observer pattern, but I'd say that it's easier to implement this way, because of contact we haven't opened a window for yet.


• In most of the time, we need to subscribe to specific kind of messages, like messages of specific type (message/presence), of specific origin (given user), or specific namespace (feature query). It's a good idea to have some general handling pattern of such - like, observer pattern, signal-slot mechanisms, or packet catchers/interceptors. It's also a good idea to make it either hierarchical or precisely catcheable (like a PresenceProcessor class catches all <Presence/> stanzas coming from a JabberConnection class, then individual viewports could catch for a specific user, ie. when a window is open with a given contact, it's a good feature that you could see when the contact goes away.)


• It's good to have separate layers of application: not all the components would be responsible, for example, processing of Jabber XML streams, nor all the layers have a hardwired reference of UI.

You can download the KDE source here.

Requirements for build:

• KDevelop, KDE libraries,etc


• gloox (0.9-pre5)

It was coded with kdevelop because it's easier to write it in an IDE, it's c++, not javascript... ;)

Screenshots

Jabber introduction slides

I've created these slides for university, it's a short introduction to the jabber protocol.

Indented for: techinical people, who heard of jabber, probably used it, but never went into "how it works" questions.
Not indented for: Those who now what iq, message and presence stanzas stand for :)

Hungarian contains thesis examples too (MSN-like custom emoticon handling, music streaming as presence information, etc).

Hungarian version

English version (without thesis examples)

Introduction

A beginning is the time for taking the most delicate care that the balances are correct

Princess Irulan (Frank Herbert: Dune)

Hi. My name is Adam Nemeth, known as Aadaam. I'm a software developer from Hungary, EU. For years I've been using ICQ, as it was the first instant messaging service, and for me, it was a standard, too. However, as years passed by, more and more instant messaging solutions came, the (at least in my viewpoint that time) ICQ-clone MSN Messenger, and the peer-to-peer VoIP software Skype.

I first used Jabber protocol sometimes around 2004 or so: I heard of it before, and some of my friends used it ocassionally, but it was a struggle with icq-transports and clients of that time. But I realized that ICQ is just a service, and as more and more people starts using instant messaging every day, we need to consider it as a part of a communication solution - most of the universities, student clubs were already providing e-mail and webhosting services, as well as some forum and so on. Realtime is getting closer as our life gets faster every day.

When Google introduced its XMPP-service called Google Talk, I was way in jabber: I knew how to use the protocol with a pure telnet, knew how to write a client and even had some ideas how to use it on web with XEP (or, at that time JEP) 124. Now I see it as a communication standard.

But much work has to be done: for example, it's not clear how we could use alias and forwarding features of e-mail. It's not clear how we could connect to accounts to each other. Practically only ejabberd provides virtual hosting, and erlang is an unusual language for an average programmer working with imperative code like Java or C++ or whatever.

There's also a problem with the protocol design itself: given that you have a heterogenous network with all kind of clients, the interoperability between those is the intersection of the supported XEPs of all clients; as more and more clients come in, it gets worse. We need to bundle the logic with the XEP itself, and there are some very good experiments out there for such.

We also need to make jabber easier to spread: embeddable clients in webpages, open hosting providers, etc... its not as easy as it seems but it can be done. Also we need a lot of features from other networks - in Hungary, mostly MSN is used today, because of custom smiley handling, for example. Teens love it, and can't imagine a client without that feature- it'd be 'boring'.

This blog will focus on mainly three topics: first, and not least, possible use cases on jabber services. Then protocol implementation examples, with simple, educational scripts in GPL or even public domain. And also there'll be some discussions about possible new protocol extensions, like the above mentioned custom smiley protocol I'm designing.