Openfire is a real time collaboration (RTC) server licensed under the Open Source Apache License. It uses the only widely adopted open protocol for instant messaging, XMPP (also called Jabber). Openfire is incredibly easy to setup and administer, but offers rock-solid security and performance.
Dear Community!
Another year has passed for this open source project and various developers have contributed significantly to nearly all of our projects. We were able to finally release Openfire 3.7 and Spark 2.6.3 under Apache 2.0 license. The most important Smack library has also seen several releases and last but not least the good old instant messaging gateway Kraken returned to us. Some great innovations were presented like SparkWeb/Redfire, Websocks and Candy. I really would like to thank all developers involved by contributing code and all users and system admins that went through this year. A very special thank you goes to Daryl Herzmann who keeps the servers healthy and Wroot for outstanding work in the forum. I would also like to single out Guus der Kinderen for his insights in Openfire architecture and the release of Openfire 3.7.
Merry Christmas to all of you and a happy, healthy and sucessful 2012
The Ignite Realtime community is happy to announce the release of version 3.7.1 of Openfire! Downloads for various platforms are available here.
Openfire is a real time collaboration (RTC) server licensed under the Open Source Apache license. It uses the only widely adopted open protocol for instant messaging, XMPP (also called Jabber). Openfire is incredibly easy to setup and administer, but offers rock-solid security and performance.
The 3.7.1 release is primarily a bugfix release. Amongst others, these issues have been addressed:
The full changelog is available on the Openfire project page.
We welcome your feedback, suggestions, tips, hints, questions and other contributions in the Ignite Realtime Community pages.
This is an implementation of WebSockets for the Openfire XMPP server. It consists a plugin for Openfire and a low-level JavaScript library suitable to be used with jQuery.
Why?
Recently, I have been involved in shaping an XMPP protocol extension (XEP) for simple application remote control of telephony devices for financial trading systems. This XEP is called Openlink and is still evolving.
I use XMPP Bosh to provide an Openlink Javascript library for web based applications and I am seeking to improve performance and scalability beyond the limitations of long-polling BOSH connections, so I decided to investigate replacing BOSH with Websockets in my Openlink Javascript library.
The Websocket protocol is close to finalising and Jetty (the embedded web server for Openfire) has been supporting WebSocket since Nov 2009 in version 7.0.1 which is the Jetty version in current Openfire 3.7.0. My first attempt of using the Jetty WebSocketServelet? class from Openfire 3.7.0 with Google Chrome web browser failed and I am not sure why. The WebSockets specification has changed a lot over the last two years and both Chrome and Jetty have kept up with it, so I was not surprised.
I therefore decided to recompile Openfire from SVN (version 3.7.1 Alpha) with latest Jetty 7.5.1 and finally got it working.
I then implemented a very thin XMPP stanza based Javascript class called openfire-websockets which exposes a minimium "Stophe" like connection object which I tested with the XMPP console application in chapter 4 of the book "Professional XMPP Programming with JavaScript and jQuery" by Jack Moffitt.
You can use this plugin from Openfire 3.7.0. Just replace openfire.jar and slf4j-log4j12.jar in OPENFIRE_HOME\lib.
If you do most of your application development with XMPP like I do, using Openfire and need fast and simple access to the low level XMPP messages as DOM elements in Javascript from JQuery right now, then take a look at openfire-websockets.js
I have received a couple of emails about Jappix MiniChat not working properly with Openfire BOSH. The main issue seems to be that the Openfire BOSH is not handling the reconnection properly as the user browses from page to page.
I'll be surprised if it did as the implementation was a few years ago and the BOSH specification has moved on since. More importantly was that it was designed to work with SparkWeb which was always resident on the web page until the user logged off. In this mode, Openfire BOSH works very well.
A possible solution for using Jappix MiniChat with Openfire is to use this same approach and keep Jappix resident on the web page as the user browses from page to page. My way of doing this is to use a main top page container with the Jappix MiniChat which puts the content web page in an <iframe> tag. I then call JavaScript on the main top page from within the iframe to control Jappix.
Of course, this does not always work especially if the content page promotes itself to be the top main page for security purposes like Goole Mail for example. In practice, I use Jappix MiniChat with my own web applications and even if my web page is hijacked, cross domain security will stop malicious JavaScript controlling my application.
If this solution will work for you, then use the attached HTML file and adapt it to your needs.
This is an update from ignite realtime community about where we are with SparkWeb
There is an Open Source HTML version of SparkWeb based on the original commercial Jive Software version and now released under the Apache 2.0 license just like Spark and Openfire. It can be found on the ignite realtime community here.
Knight Raider has worked on the Flash version of SparkWeb and has made it compatible with the ignite realtime latest version of XIFF. His version compiles with Flex Builder using Flex SDK 3.0 for Flash Player 9 and above. It can be found on the ignite realtime community .
I have made a few more changes to make it compile with the latest Flex SDK 4.5 for current Flash Player 10.3 and above and uploaded it to the SparkWeb SVN. The code can be checked out using
https://svn.igniterealtime.org/svn/repos/sparkweb/trunk/SparkWeb2
Knight Raider has volunteered to work on this. We plan to to add Jingle-based audio, video, file transfer, screen sharing, etc and make it look better than this
Finally, work has started on RedSpark which is yet another web client for Spark, but is tightly integrated into Redfire and will be compatible with the Redfire plugin for Spark. It is extending XIFF with the new RTMP/RTMFP connection classes and has a Facebook/Google type chat user interface that combines both HTML5 and Flash to support a softphone (red5phone), audio/video in both 2-way and multi-user chat with screen sharing (red5-screenshare) and p2p file transfer using RTMFP.