Good things come to those who wait!

The Ignite Realtime Community is pleased to announce the beta for the next release of Openfire. This release contains a number of important  fixes and improvements to stability and XMPP protocol compliance. You can find a full list of fixed issues here. This beta is also the first version of Openfire to be released by the Ignite Realtime community under the Apache License v2.0.

You can download the 3.7.0 beta release here. Please provide us your feedback on the Ignite Realtime support forums. It would be helpful if you would tag your comments, discussions and questions with a tag that reads "openfire370beta"

As always, but particularly since this is a beta release, make sure to backup any existing version of Openfire and the persistent storage that it uses, before upgrading!

Some important security related notes to this release:

• Openfire no longer ignores the system property to disallow password changes via XMPP. With previous releases, it was not possible to prevent users from changing their password via their XMPP connection. (CVE-2009-1596)
• Fixed a XSS attack on the admin console login form.

Protocol compliance improvements:

• Publish Subscribe (PubSub)
• BOSH (http-bind) xml namespace compliance fix.

Some highlights of this beta release:

• Improves how Openfire handles "idle" connections. Some of you may have  the system property xmpp.client.idle set to -1 to work around  previously broken behaviour. You may now let it default to 6 minutes or  set it to your preference.
• Improved Openfire's caching to be less prone to memory exhaustion by correctly calculating cache size usage.
• Fixed a bug where admin console login into a newly installed Openfire server would fail until restarted.
• Fixed a bug with shared rosters within a LDAP environment.
• Openfire now ships with the latest JRE (1.6.0u21).
• A memory leak with the Personal Eventing Protocol (PEP) was fixed.
• Openfire's custom log interface has been replaced with SLF4J and a Log4J backend.
• Fix issues with self signed SSL certificates.
• A number of improvements and fixes were made to the Multi-User Chat (MUC) configuration pages on the admin console
• There were also some improvements made to the plugins.
• There are also French, Russian, and Lithuanian langauge translation fixes for Openfire and some of the plugins.

redfire is the future of the Red5 plugin for Openfire.

In an attempt to maintain a single version of Red5phone and keep Openfire (ver 3.7.0) in step with Red5 (ver 0.9.1), I have chosen to embed Openfire inside Red5 instead of the other way round.

I have posted the first version at http://code.google.com/p/redfire/

This first version is just only Openfire 3.7.0 beta running as a web application in Red5. You acess Openfire web console the same way. http://your_server:9090

I will be adding the improved redfire sparkweb client with latest versions of red5phone, red5screen-share and support for onesocialweb later on.

As you might or might not know, the XMPP Standards Foundation has been accepted as a mentoring organization for the 2010 edition of the Google Summer of Code. Amongst others, specific project proposals for the IgniteRealtime community are available. They are being discussed in GSoC 2010 Projects. The deadline for student applications is next Friday (April 9th, 19:00  UTC). If you are interested, head over to the XSF wiki for  more information!

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.