We have just released version 1.2.1 of Tinder. This version is a bugfix release, that improvement the AbstractComponent implementation that was added in version 1.2.0.

We are happy to announce that the clustering plugin is now available as an open source plugin. The clustering plugin adds support for running multiple redundant Openfire servers together in a cluster.  By running Openfire in a cluster, you can distribute the load amongst a number of servers, as well as having some form of redundancy in the event that one of your servers dies.

By making this functionality open source we now made 100% of the old Enterprise plugin open source. The reason why the clustering plugin came last is that it relies on Oracle Coherence, that is a commercial product, so to make it open source was a little tricky. At the end what we did was to open source our implemented functionality but to use this plugin you will need to get a valid Oracle Coherence license. The readme file explains the steps to follow to install this plugin. Moreover, it also explains how to setup your environment if you plan to develop new versions of the plugin.

Have fun,

  -- Gato

We've just released a new project, named Tinder. Tinder is a new 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 been moved from the original projects into Tinder, preserving al of the existing features and functionality. Most of the code that's now in Tinder is based on the org.xmpp package implementation that previously existed in Openfire and Whack. This is the code that defines classes such as Packet, JID, IQ, Component and their extensions. Additionally, some multi-purpose code (such as the DataForm and Result Set Management implementations have been moved to Tinder as well.

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 and Whack 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, in which we capture the first steps of the development of Tinder. As always, you're invited to contribute. We're looking forward to hear your suggestions, thoughts and ideas. If you're interested, you can find more information on the new Tinder-related community space and project page that have been opened on IgniteRealtime.org.

SAN JOSE, Calif. — Jan. 20, 2009 — Adobe Systems Incorporated (Nasdaq:ADBE) today announced plans to publish the Real-Time Messaging Protocol (RTMP) specification, more..

This is good news for the Red5 project and the Red5 plugin for Openfire with the Red5phone Flash phone. It will be interesting to see if the XMPP Standards council will give the Jingle RTMP Transport proposal another consideration.

After Gato made this suggestion in my last blog, I decided to move this request to the top of my to-do list as I also need it for another project I am currently working on.

How does it work?

I am using the Flex Dashboard developed by ESRIA which was donated to the Adobe Developer Connection. Plugins are presented in a pod layout called a View. Each View occupies a Tab in the SparkWeb ChatWindow. You can modify Views by dragging and dropping pods to a different location and minimizing, maximizing, and restoring pod windows. View changes are saved using a LocalSharedObject. View configuration data is loaded from sparkweb/plugins/plugins.xml with values in plugins.xml indicating which swf file to load for a particular pod within each View.

<views>

<view id="view0" label="Plugin Demo">
  <pod id="app01" title="User Moods" dataSource="plugins/moods.swf" />
  <pod id="app02" title="User Tunes" dataSource="plugins/usertunes.swf" />
  <pod id="app03" title="Demo" dataSource="plugins/demo.swf" />
</view>

</views>

SparkWeb will load each pod SWF file and call the method setParentApplication passing it the SparkWeb root Application object. From this object, you can navigate your way to access all other SparkWeb public objects and even add eventhandlers on events like NewMessage for example.

To get a feel of what can be done, I decided to implement the User Tunes and Moods PEP (personal eventing protocol) applications. See Armando Jagucki's blog for more details about PEP in Openfire. The source code to the demo plugins is in the src/plugins folder.

For those interested, the latest version of Red5 Plugin for Openfire can be found at _http://red5.4ng.net/red5-0.1.06.zip. Remove comments in plugins.xml to activate the demo.

We've released the first beta of Smack 3.1.0. Although it's been about a year since the last release, this version is jam-packed with great new features and bug fixes. Check out the changelog for full details.

We expect the beta process on the release to be relatively quick, but much will depend on the stability feedback we get. There are also a few last changes that we're looking to get in before the final release.

A great book about installing and administering Openfire has been released: Openfire Administration, by Mayank Sharma (a contributing editor at Linux.com). Some of the topics covered:

• Installing Openfire
• Administration of server settings and users
• Integration with Active Directory and LDAP
• Tuning Openfire for large numbers of users and high performance
• Enterprise features like logging and auditing
• Much more...

So far, I've only just started reading through the book in detail. The writing seems to be clear and detailed, while keeping a light-hearted tone. I also love the fact that the author includes lots of pictures -- it makes understanding some of the administration tasks much simpler.

We're thrilled to see the first book about an Igniterealtime Open Source project. If you get a chance to check it out, please let us know what you think.