Introducing Tinder, an XMPP object implementation library

Welcome to Tinder!

Tinder is a Java based XMPP library, providing an implementation for XMPP stanzas and components.

Tinders origins lie in code that’s shared between Jive Software’s Openfire and Whack implementations. The implementation that’s provided in Tinder hasn’t been written again “from scratch”. Instead, code has moved from the Openfire and Whack projects into Tinder, preserving al of the existing features and functionality. So, what code will combine into Tinder? Notably the org.xmpp package implementation of Openfire, which defines classes such as Packet, JID, IQ, Component and their extensions.

Why a new project?

Parts of the code of Openfire are useful in other contexts than that of an XMPP server implementation. Developers might, for instance, want to use the XMPP stanza implementation within other projects. Having to include Openfire as a dependency of such a project is quite a bit of overkill. In such an example, it would be useful to have a small project that you can include, that offers you a lightweight XMPP object implementation, without the rest of the features that Openfire offers. Enter Tinder. Tinder will allow developers to re-use parts of Openfire, without having to include Openfire itself.

There’s other benefits to Tinder though:

Tinder will replace some most of the duplicate code that’s currently shared in Openfire, Whack and ConnectionManager projects. Removing duplicate code will make it easier to maintain and develop these projects. By delegating the implementation and maintenance of the low-level XMPP implementation, Openfire, Whack and other developers will be able to focus on the development that adds value to their project.

On the flip-side of that medal, you can argue that the ‘core’ code that will make up Tinder deserves a bit of dedicated development attention (unit tests, bug-tracking, stuff like that). This would benefit any attempt to really fine-tune the code, for example for high-performance tuning. Currently, the code is a bit put in the shadows of the other projects (of which they are part of).

So, will this replace Smack (the library that provides the base of Spark)?

No, definitely not. Smack offers a full-fledged XMPP client implementation, while Tinder only defines some XMPP building blocks. Tinder provides some basic objects on which a client library such as Smack could be build. However, Smack does not share the same code base as Openfire, Whack and the ConnectionManager do. It’s therefor unlikely that Tinder and Smack will be merged in the foreseeable future - there’s simply to much difference.

What’s next?

We’ve wrapped up a Initial roadmap, project Tinder, in which we capture the first steps of the development of Tinder.

As always, you’re invited to contribute.

Hi,

I don’t speak english very well.

Then I don’t understand somethings.

Does the Tinder is an application like Openfire or just a kind of library who developers can use?

Thanks.

Hamilton

Tinder is a library, not a standalone application.

can i use tinder to create a java ee server, i do not want to use openfire, beacuse my server is jboss

thanks

Definately! Tinder provides implementations of most of the baseic XMPP entities, such as XMPP stanzas (Packet.class), Jabber identifiers (JID.class) and components (Component.class). It does not include any logic related to routing of stanzas, which is a key responsibility of a XMPP server implementation, of course. You’ll have to write that yourself.

Smack is a client library. You can use it to log into an XMPP domain and make use of the functionality it provides. Typically, Smack is used to implement a instant messaging client.

Tinder is a low-level XMPP library. It provides Java implementations of basic XMPP entities, such as Stanzas (called ‘Packet’ in XMPP), JIDs and Components (which typically implement part of the functionality of an XMPP server). Although in theory, Tinder could be used to implement client functionality, it currently is primarily used on the server-side. Both Whack and Openfire (an XMPP server implementation) use Tinder-defined entities. Smack does not use Tinder at all.

Hy guys,

I want to extend the IQ class and share this implementation on my client using smack and on my server using openfire. But, currently, the smack and openfire don’t has the same IQ class. There is a way for share an extension from the IQ class on both sides(server and client)?

Thanks!

Sadly, no.

OK. Thanks for the feedback!

I’ve had some success with using org.dom4j.io.DocumentSource

to transform to and from dom4j (which is used by Openfire).

Maybe you can use a JAXB annotated code base for your IQ payload class, then transform it to/from Dom4j (for Openfire plugin) using javax.xml.transform.TransformerFactory, and something similar for your Smack IQ Provider.

I’ve written methods like which do the transformation:

static fromElement(org.dom4j.Element)
org.dom4j.Element toElement()
1 Like