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.

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.

I am proud to announce that I have successfully completed my Google Summer of Code Project. As we hit the official pencils down date, I thought it might be good to publish results and final toughts.

I started the project in time and completed it 3 working days later than planned, though it could require more effort if we didn't change our goals. I cooperated with Tomas and Tobias to fix the flaws I couldn't notice during development. Changes I made to Openfire and XIFF are listed here and here. All changes have been imported into trunk and hopefully be included in next releases.

It was a wonderful experience to work on Openfire and SparkWeb, especially with my mentor Gaston. Even if my GSoC project is complete, I feel there'll always be something to do for me with Jabber. I am having fun with Jabber, and planning to continue working on Jabber development as a community contributor.

I would like to thank Google for giving me such a great opportunity. I also thank David Smith and Peter Saint-Andre for their excellent support.

See you around!

Hey all.

I have been selected as the new project lead for both the SparkWeb and XIFF projects here at the Ignite Realtime community. For about half a year David and I were the only developers contributing code to those projects on a full-time basis -- before SparkWeb's source was even opened up. I added initial support for shared groups, group chat invitations, kick/ban/nick-change announcements in group chat, various bug fixes, and a bunch of other little features here and there. With my previous work on SparkWeb I have seen first hand how its code has matured over the year. I think it is in a 'good' state right now, but clearly there is always room for improvements.

David has made a lot of necessary refactorings in the past that have improved its performance and Safa is currently ensuring SparkWeb is fully compatable with BOSH 1.6. Also, we have various other patches containing excellent improvements from other people in the community that will be included in an upcoming release. These two projects now have a decent amount of activity from outside of Jive, which is great.

From some recent conversations in the weekly chats it is clear to us that people feel comfortable with Openfire, the server -- and that what they are expecting to see is a client evolve to the same degree. I would like to hear more about this perspective so I can focus to make it happen in SparkWeb's use-case.

Interested in getting involved yourself? Well, what are you waiting for? This is an open source community after all... grab the source and join the fun. Send any of your code contributions, ideas, or feedback to me and let's make the most excellent XMPP web app/lib out there!

--Armando

Earlier today I exported our svn repository for SparkWeb and committed the intial import to the new open source repository! Instructions for getting and building the source are available. Getting and Building SparkWeb. A chat room for discussion of SparkWeb development can be found at sparkweb@conference.igniterealtime.org. I'm looking forward to seeing what the community can do!

David recently blogged about how XMPP is Taking Over the World  starting with the recent AOL tests and his hopes that Microsoft, Yahoo, and QQ would follow AOL's lead.

Well, this must have got Matt thinking about how XMPP really could take over the world.  His vision of XMPP is moving way past IM with a grand vision for how XMPP could be the future of cloud services.

I'll let you read his entire post over on Jive Talks, but here is a little snippet:

There's a new firestorm brewing in web services architectures. Cloud services are being talked up as a fundamental shift in web architecture that promises to move us from interconnected silos to a collaborative network of services whose sum is greater than its parts. The problem is that the protocols powering current cloud services; SOAP and a few other assorted HTTP-based protocols are all one way information exchanges. Therefore cloud services aren't real-time, won't scale, and often can't clear the firewall. So, it's time we blow up those barriers and come to Jesus about the protocol that will fuel the SaaS models of tomorrow--that solution is XMPP (also called Jabber).

Matt's post is also on Digg.

Openfire is the award-winning instant messaging server known for its simplicity, elegance, performance and extensibility. With each new major release, scalability has been improved; however, being able to scale a lot without redundancy or high availability poses a risk to every connected user if the single server goes down.

After many months of work that risk is now part of the history. Openfire Enterprise 3.4.0 provides support for clustering. Clustering will let you run Openfire on several machines serving the same XMPP domain. Clustering can be enabled with just one click from the admin console. Machines running Openfire Enterprise will automatically meet between them to form a cluster. With clustering you not only get high availability but also improved scalability. In our internal load tests, we got more than half a million concurrent connections sending lots of packets in a cluster of just 2 nodes.

Another nice addition to Openfire Enterprise is SparkWeb. Users can now connect to the server and chat from your website. Read the SparkWeb: Next Generation blog post for more information.

On the open source side we also have excellent news. More than 30 new features and more than 30 bugs were fixed. Personal Eventing via Pubsub was added so you can now publish your geo-location, music you are listening to and let subscribers be alerted.  From the admin console you can manage users roster. Moreover, it is now possible to retrieve photos from LDAP and use them as users avatars. The complete set of changes can be found here.

You can download Openfire from here. Openfire Enterprise can be downloaded from here.

Enjoy,

Openfire Team

Monday, after a long period of heavy development, I finally put out version 1.1.0 of the IM Gateway plugin! A total of 85 issues from JIRA were closed along the way and I'm quite pleased with the results. Along the way there were a number of stumbling blocks where I would just about be ready to release and something major would come up, and I certainly did not want to release anything with serious issues going on. As development continued, more and more features became interesting to me and were implemented. Since 1.0's release, I've had a number of helpful folk step up and offer patches, testing, code, translations, and help with libraries I depend on. I want to take a moment to thank everyone who contributed in any way! You are all invaluable to me!  There are a number of big plans coming for the next major release, but I wanted to highlight some of the things from 1.1.0's release and even comment on some of it!

First off, there's XMPP/Google Talk support. One might ask, why do you want XMPP support when there's s2s? That's a question that's been fought many times in the past and typically results in nothing being decided. Well I decided to implement it and then another helpful person (thanks Mehmet!) took my piddly start with it and turned it into a full on transport for the plugin. After implementing it I found myself using it with some accounts I had seen no reason to add to my Adium X config but decided hey, if I can handle it server side, then I'll just carry it around with me. Has been working out really well!

Then there's Gadu-Gadu support. This is a protocol I did not expect to ever implement. Why? Everything about it is Polish. I couldn't find my way around the web site enough to even download a copy of the client.  However, I said early on that if someone would translate or help me download or generally help me get it set up and there was a good API out there, I'd do it. So thanks to Marcin for stepping up and helping me get this started! The API itself was amazingly enough the easiest API to work with yet!

And what about SIMPLE support? Thanks to Ravin and Patrick for writing this support as I wouldn't have even known where to begin! I still don't understnad SIP/SIMPLE. Who knows if I ever will. But the transport sure works with my OpenSER server! I'm hoping some folk will take a look at it so I can get a feel for what it does and does not work with and maybe I can work with them to tweak it to work correctly with various implementations.

Another interesting thing that was added is an XMLRPC interface so site administrators can write their own web front ends for users to register with the various transports. That way folk could use some various standard web look and feel for the registration, and/or their own authentication mechanism, or even just something they consider "nicer" for their users, and dodge around typical requirements of registering through a client or requiring the admin to do it for them.

A lot of the inner workings of the plugin were redone, making things a lot more efficient in terms of network traffic and overall coding structure. I don't know that anyone but me will appreciate the reworkings of the code, but hey. =)

One of the interesting things that came about is that I ended up as the lead developer for Martyr, a very cool IRC library. IRClib just wasn't getting it done for me so I tried out Martyr, adored it's structure, and offered to help improve it. It's already led to a far better IRC transport than what I had before.

Beyond that I want to thank the folk from nimbuzz for creating the wonderful project OpenYMSG (a fork of YMSG) that fixes a number of problems I kept running into in the past! Through their improvements Yahoo support in the IM Gateway plugin was promoted to being considered stable!  On top of that they've helped me out some with JML, the library that handles MSN support. Great work folk!

Well that's enough of me, I'm excited about things to come though and I hope you all will join me in that excitement and continue to help me with testing, ideas, and whatever! =)