1 2 Previous Next

Ignite Realtime Blog

23 Posts tagged with the openfire tag

We are very pleased to announce the release of Openfire 3.6.0!  It has been a long time coming and may well include the highest number of bug fixes and improvements we've ever had in a single release.  Don't quote me on that, but it's certainly the largest number I recall seeing.  =)  While the bulk of them are bug fixes, there are a couple of big improvements I would like to highlight!

 

Clearspace Integration Improvements

We've improved upon the integration between Openfire and Clearspace quite a bit.  Most are bug fixes and performance improvements, but also some new backend features that further solidify the bond if it is set up.  Openfire now includes a Clearspace tab when integration is enabled so help make sure the link is performing properly.  On top of that, there are a lot of features in place in preparation for the addition of real time chat support in Clearspace.  More information will come on that at a later date.  We've also renamed the tables Openfire uses to make it easier to install it alongside other products in the same database, if you so choose.  The automatic upgrade procedures will take care of all of the hard work for you, so you shouldn't need to give it a second though.

 

LDAP Support Improvements

Openfire's LDAP support had some holes in it here and there that should be filled now.  Altbasedn, for example, was not used everywhere.  There is now support for alias following (or rather, turning it off), paged results (to make sure to get all of the available results instead of a subset), and a number of bug fixes for existing functionality.  Internally, a lot of the code has been cleaned up.  I still have a couple of things up my sleeve here and there for a future release, but I'm quite pleased with how this is looking now.

 

Multiple Conference Services

Every wished you could have more than one conference service set up with different rules?  Maybe you wanted one for public access with no room creation rules and restrictions, but also wanted an internal "protected" service that abided by strict rules.  Maybe you just wanted to set up some sort of specialized set.  Maybe you never wanted -any- conference services and just wanted to delete them.  Whatever the reason you might have, you can now set up as many or as little as you want.  In some cases, plugins may even be able to take advantage of a specialized service setup.

 

BOSH (HTTP Binding) Improvements

With many thanks to our Google Summer of Code student, Safa Sofuoglu, we now have updated BOSH 1.6 support, and a ton of misc bug fixes and improvements.  Improvements in this area were also performed on the connection managers!  I encourage you all to read about it in his report:

GSoC 2008 Report: Openfire and SparkWeb

 

More Configuration in Database

The openfire.xml config file was getting bloated and a lot of the configuration in it could easily have been moved into the database.  As a result, we've moved just about everything that doesn't fall into a category of:

  • how to connect to the database itself
  • config info specific to host itself

 

Why you might ask?  In a clustered environment, it makes it so you can set Openfire up once and now have to reconfigure the providers and such for each cluster member individually.  It also paves the way for support for things like, admins stored in the database, which means you can update the admin list on the fly, instead of having to edit openfire.xml and then restart the server.

 

Plugin Updates

It's important to update the following plugins to account for changes in the 3.6.0 API:

  • User Search
  • IM Gateway
  • Fastpath
  • Monitoring

 

Where Do I Get It?

 

You can download Openfire 3.6.0 here.

You can see the entire changelog here.

You can view the documentation for 3.6.0 here.

Plugins can be downloaded from the admin console or here.

7 Comments Permalink

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!

6 Comments Permalink

I have updated the XIFF library to be compatible with BOSH 1.6. As SparkWeb is based on XIFF, most of the information here also applies to SparkWeb. Main good news are:

  • Login phase and communication using BOSH is noticeably faster thanks to new overactivity rules of 1.6.
  • BOSH connection is tested and working with Openfire, Tigase and ejabberd.

 

Additional Work

 

  • Added logging support to XIFF using Flex logging API (mx.logging).
  • Moved SASL logic from XMPPBOSHConnection to XMPPConnection, so now both connection types (BOSH and socket) share the same authentication code. Previously, socket connection was using non-SASL authentication.
  • Cleaned up some dead code and made BOSH connection class more configurable.
  • Fixed a few Openfire BOSH issues that appeared when testing XIFF.

 

Known Issues

 

This updated version of XIFF will be fully compatible with the updated Openfire and Openfire's BOSH update will be included in version 3.6.x. However,  there is an issue with Openfire versions released before the update.

 

According to XEP-0206, after a successful authentication, clients should send a body with xmpp:restart attribute set to true. But older Openfire versions do not recognize xmpp:restart, handling the request as if it was a polling request. Thus, it responds to the client after 30 seconds.

 

If you use the updated version of XIFF or SparkWeb with a version of Openfire that does not support BOSH 1.6 (i.e. lower than 3.6), please be aware that you will be experiencing a latency of 30 seconds during logins.

0 Comments Permalink

When SparkWeb became open-source, I took a look at the source code and found it had more features than the Flex-based XMPP client I was co-developing for the Red5 Plugin. It therefore made sense to migrate the Flash audio and video features we had developed for our client to SparkWeb and make it compatible with the Spark and Openfire Red5 Plugins and package it as part of the Red5 plugin. The downside to this that the modifications to the Red5 version of SparkWeb makes it out of sync with the official SVN and it could possibly become a fork requiring a name change later on.

 

So what does the Red5 SparkWeb offer?

 

  1. A plugin container for SparkWeb. I noticed  that quite a number of users are asking for a plugin to deploy SparkWeb. My advice would be to try the Red5 Plugin.

    Configure  Index.html and point your users at

    http://your_server:nnnn/red5_webapp_name/sparkweb

    Where nnnn is your HTTP-BIND port number (default 7070) and red5_webapp_name is your default red5 web application name (default red5)

  2. Enables use of the Red5 plugin audio and video features with both Spark and SparkWeb. You can't do video messaging and the video roster is replaced with visual presence (see below). You can make audio/video calls and share your desktop with your contacts. Each call record is logged in openfire and can be queried by the administrator with the Openfire SIP plugin.

  3. Makes SIP phone calls between Spark and SparkWeb users. All SparkWeb SIP calls are logged with the Openfire SIP plugin as well.

  4. Provides webcam support. If you have a webcam installed on your PC, it will be automatically detected and will be used instead of your vcard photo. You can disable this in index.html. You can add or replace your vcard photo with a snapshot of your webcam when you edit your profile. You can also publish snapshots from your webcam as visual presence to all your contacts. What this means is that all your contacts will have  a snapshot of your webcam in their rosters. The interval between snapshots is 60 secs by default and can be modified in index.html. See a draft copy of my proposal to extend XMPP with visual presence. Please feel free to post comments at the bottom of the document.

I also made a few cosmetic changes to my taste and added sound effects for incoming calls and instant messaging. I added some code to improve the loss of focus detection by tracking Flash application activation/deactivation messages and mouse movement. If you use Internet explorer and enable pop-ups, you will get a pop-up in the bottom right corner of the screen with a photo, name and first line of the incoming messaging if you are outside of SparkWeb when a new message arrives.

 

I am hoping to add fastpath support and a calendar to SparkWeb next.

7 Comments Permalink

I am working on BOSH support of Openfire and SparkWeb as part of the Google Summer of Code 2008. As we got past the midterm evaluations, my mentor Gaston and I thought it would be good to inform the community about what I have done so far.

 

My proposal involved updating and improving Openfire's BOSH support by updating the implementation to BOSH 1.6, and migrating Apache MINA as its connection provider.

 

I started with creating a load test environment to see Openfire's current performance, and created a document explaining how to use it. Then I ran some load tests using that environment. Unfortunately, the test machines I used were not enough to produce desired results.

 

As the next part of the project, I updated Openfire's BOSH to support both 1.5 and 1.6. Here is a summary of the update:

 

  • Added 'hold' and 'ver' attributes to the session creation response.

  • Fixed version checking. Before it was done using a double variable, which  may show that 1.5 is newer than 1.10.

  • Script syntax support has already been added before. Finetuned it to prevent  caching of responses.

  • Implemented in-order message forwarding (JM-1412), because further work seemed to be depend on this implementation. This is the part that took most of my time, also which made me to get more familiar with the code  after long debugging sessions.

  • Implemented acknowledgements, which was intoduced in version 1.6.

  • Added support for session pauses, which was also new for 1.6.

  • Implemented overactivity checking. In 1.5, there was only 'polling  too-frequently error', and a little description about it. Version 1.6 introduced a new section for overactivity, and has a detailed description of which  circumstances should be considered overactivity.

 

With this update, I have seen that some BOSH issues I was not aware of (JM-1245, JM-1246) have also been resolved. The update has been merged into Openfire trunk, so you can grab and test it.

 

After the update, I started to investigate how to migrate to Apache MINA, and found out that it would be harder than we expected, because the version used by Openfire, 1.x, did not have any http support. We had also other alternatives, like Grizzly, so we deferred the decision about connection providers until we do some tests on them.

 

I am currently working on SparkWeb to make it fully compatible with BOSH 1.6. In the meantime, I am cooperating with Tomas Karasek, who is developing BOSH for Gajim, to resolve any BOSH related issues in Openfire.

 

I am open to any ideas/suggestions.

9 Comments Permalink

The Fastpath product allows a company to provide support through the web. Users can use their own XMPP client or the provided web client to initiate a chat request. The request will be routed to the proper queue and agents will be offered the chance to answer the request.

 

Today we made the source code of the web client part of Fastpath available and a new version was released with the change in the license. You can download the new version from the plugins page.

 

Use the following SVN access to get the source code of the web client:

 

svn co http://svn.igniterealtime.org/svn/repos/fastpath/webchat/trunk webchat

 

The web chat client relies on the workgroup API that has not been moved to the open source repository yet. That is our last task in this long process of making Fastpath open source.

 

Enjoy,

 

  -- Gato

10 Comments Permalink

It took us some time but we finally made it. The Enterprise Edition plugin has been broken into smaller open source plugins as mentioned in the Turning Openfire Enterprise into an open source product blog post.

 

The new plugins can be found here:

 

With these new plugins the total number of official open source plugins is now 17. If we add the clustering plugin that is commercial and the 3 beta plugins that includes the popular Red5 plugin the total number of plugins comes up to 21. Finally, more plugins can be found in the Non-Jive Openfire Plugins document.

 

Enjoy,

 

The Openfire Team

32 Comments Permalink

We are pleased to announce the release of Openfire 3.5.1, now with even more openness!  This release represents the first stage of the Enterprise plugin split into open source plugins.  We're very excited to be able to provide these to everyone for free, and seeing what the community does with them, both in terms of contributed code and use case scenarios.  So lets talk about some specifics.

 

New Plugins!

 

  • Monitoring: Adds support for server statistics and chat archiving and reports.

  • Fastpath: Support for managed queued chat requests, such as a support team might use.

 

These are the first two pieces of the open sourced Enterprise plugin.  Client management is coming very soon, as is clustering.  SparkWeb will also be released tomorrow as a separate product.  So you might be wondering, hey, why is there an Openfire Enterprise 3.5.1?  Well, due to the lack of all of the plugins being available right now, we've provide 3.5.1 for existing enterprise customers to make use of.  It includes some important clustering fixes though!  (as will the clustering plugin when it is release)

 

Important, Seriously, Pay Attention, Read This

 

 

If you install the Monitoring and/or Fastpath plugin, make absolute sure that you read the readme first!  There are included instructions for how to migrate your database from the Enterprise plugin to the new plugin database tables.  If you have ever run the Enterprise plugin or the old Fastpath plugin before it was integrated with Enterprise, make sure you don't forget this or you will be unhappy!

 

 

Big Connection Manager Improvements

 

The connection managers have been updated to bring HTTP binding up to date and a couple of library upgrades that include a number of improvements.  It is important to note though that the conf/manager.xml file has been updated and you will need to update yours as well.  The new http binding section that you will need to add is described here.

 

Ok Fine, Where Do I Get It?

 

You can download Openfire 3.5.1 here.

You can see the entire changelog here.

You can view the documentation for 3.5.1 here.

Plugins can be downloaded from the admin console or here.

44 Comments Permalink

As you may have already seen, Openfire 3.5.0 was released today alongside it's good friend Clearspace 2.0!  We are excited to put out this release as it strolls alongside a number of new announcements, new features, and is sporting a brand new outfit in the form of a new look and feel for the admin interface.

 

Now, in light of the announcements regarding the Enterprise plugin becoming open source, you may be wondering why you can see an updated Enterprise plugin available.  We are providing this plugin for our existing enterprise customers until the separate split-up plugins are released.  Those of you waiting for the open source releases, please stay tuned!

 

For our Clearspace customers, this new version of Openfire integrates at a much more intense level than before.  Instead of simply providing presence to Clearspace, and requiring you to point both Clearspace and Openfire at something like LDAP to have the same login setup, you can now have Openfire speak directly to Clearspace.  It will pull it's users and groups, as well as pass authentication through Clearspace.  Setup is a breeze, as you have one screen of setup in Clearspace and one screen of setup in Openfire and you are done.  And we're not stopping there.  Future releases will include even more integrations between the two!

 

Is Clearspace integration the only new thing in Openfire 3.5.0?  Of course not!  We've now got the ability to disable accounts, security audit logs for admin events, easy to take advantage of invisibility, and did I mention the pretty new admin interface?  We went over a lot of these new features in a previous blog post, so I won't bore you with a complete rehash of all of them. 

 

One word of warning, due to the nature of CSS not wanting to easily refresh itself, you may need to shift-reload in your browser for the new admin console to look correct.  And don't forget to update your plugins after upgrading to 3.5.0!  Some of them are affected by API changes!  (specifically: User Search, IM Gateway, MOTD, and SIP)

 

This has been a very exciting day for us here at Jive and we hope exciting for you as well!

 

You can download Openfire 3.5.0 here.

You can see the entire changelog here.

You can view the documentation for 3.5.0 here.

Plugins can be downloaded from the admin console or here.

0 Comments Permalink

We're in the process of making the Openfire Enterprise module Open Source (see Matt's blog). The Enterprise module provided several areas of functionality that were available as a single plugin. A quick list:

 

Reporting - a dashboard with statistics about server load, user sessions, chats, groupchats, etc. and support for executing reports.

Chat archiving - support for tracking conversations taking place on the server. Both one-to-one and groupchat conversations can be archived.

SparkWeb client - the web-based version of the successful Spark client.

Clustering - support for running several machines hosting the same domain. Thus adding fail-over and better scalability of the server.

Client control - controls whether certain features are available or not in the Spark client (e.g. file transfer, broadcast, groupchat, etc.). Moreover, it is also possible to specify which clients can connect to the server, push new versions of the Spark client and populate rosters with groupchat bookmarks.

Fastpath - provides rich web-based click-to-chat functionality with support for requests to the best available operator in queues. It's ideal for web-based realtime helpdesks.

 

Turning a commercial product into an open source product implies more effort that one would initially estimate. Therefore, we are going to break this process in two stages. During the first stage we will offer several plugins that will include the features listed above (with the exception of clustering). Our clustering solution relies on a commercial product and will not be made Open Source. The output of the first phase will be:

 

  • Reporting and Chat transcripts plugin - this plugin will include the reporting and chat transcript functionalities

  • SparkWeb - SparkWeb will be available as a separate project and not as an Openfire plugin

  • Client Control plugin - the ability to manage clients will be available as an Openfire plugin

  • Fastpath plugin - the Fastpath application will be composed of an Openfire plugin and the WebChat plugin. The webchat.war plugin can be deployed to Openfire as a plugin or can be deployed to your application server (e.g. Tomcat) of choice.

 

The second stage of this process will include:

 

  • Reporting and chat archiving - This functionality was available as a plugin in stage one. For stage two we will evaluate making it part of the server itself.

 

Stage one is planned for April 27th, 2008. That means that two weeks from now we will have most of the functionality included in the enterprise edition available as open source plugins. No clear date has been assigned to stage two but it should take place a few months after stage one.

26 Comments Permalink

I'm happy to announce that we're making most of Openfire Enterprise Open Source! First, a bit of context: for the past couple of years, one way that we (Jive Software) have monetized our Open Source work on Openfire and the other projects on igniterealtime.org has been through Openfire Enterprise. Openfire Enterprise addresses the Enterprise Instant Messaging (EIM) market by adding rich reporting, archiving, and control features on top of Openfire. Since we released Clearspace last year, Jive has become super-focused on social collaboration and communities. That's pretty different than the EIM market and it's become increasingly difficult for us to serve both markets with our limited resources. Instead, we want to focus our Openfire work on real-time social and collaborative features and monetize our Open Source efforts through Clearspace integrations.

 

Existing Customers

 

Discontinuing a commercial product is always a difficult decision and one of our biggest concerns is not leaving existing customers in a lurch. We'll continue to provide support for Openfire Enterprise through existing support contracts and believe that making the Enterprise components Open Source is the best possible outcome for customers given the options. We remain strongly committed to the Openfire project and are pretty excited about what's coming in the future.

 

A Few Details

 

Gato will have a follow-up blog post with a lot more details about what we're releasing as Open Source and how, but I wanted to highlight two items. Sparkweb is our flex-based web client based on XIFF and will become Open Source. The client is already very feature rich and polished, and we're actively making many code improvements to it, as it's a shared code base with the real-time client features we're building into Clearspace. Second, the clustering functionality in Enterprise will not be made Open Source. Part of the reason for this is that we use a third-party commercial library for clustering  that can't be Open-sourced.

 

Let's Go Get 'em

 

One of our hopes with this move is that the last possible objection to deploying XMPP-based instant messaging at every organization in the world is now removed. Now, everyone will have access to an open standards solution that satisfies all the needs of IT departments... for free. We think that's great news for the community and getting our technology deployed even more widely is good for Jive Software as well. We hope you'll join us in spreading the word.

32 Comments Permalink

Most every day, the United States is impacted by high impact weather events.  These events range from hurricanes to tornadoes to winter storms. The National Weather Service (NWS) is tasked with forecasting and warning about these high impact events to save lives and protect property.  The process of alerting and mitigating these high impact events involves the close collaboration of partners in the broadcast media who are federally mandated to relay weather alerts to the public, and emergency management who organize and respond to weather threats. Historically, these groups have operated on islands during weather events with one way communication systems providing data.

 

Starting in 2000, some parts of the country started experimenting with Instant Messaging technologies to bridge these islands during high impact weather.  At the time, these involved the use of proprietary protocols and clients in an ad-hoc manner.  In 2005, a group of interested parties in Iowa started looking for a scalable, secure, and open source / standards system that could provide the level of flexibility necessary to support the real time collaboration of broadcast media, the NWS, and emergency management. This effort was called IEMChat.

 

After a perusal of IM technologies, IEMChat implemented XMPP and choose the Openfire server to power the project.  Openfire's ease of installation, functional administrative console, stability, and active support community has provided the foundation for the IEMChat project to flourish.  In a short 2 years, IEMChat's use has spread to over half of the country with 85+ NWS offices, 450+ broadcast media outlets, and hundreds of local emergency managers participating.  IEMChat has been put to use in recent high impact weather events such as the Super Tuesday tornado outbreak that ravaged the states of Arkansas, Tennessee, Kentucky and other states.

 

Daryl Herzmann, IEMChat's primary developer who is based at Iowa State University,  says that Openfire has made the project possible. “Openfire provides us a robust and stable XMPP feature set supported by a fantastic community on Igniterealtime.org.  The developers' active support on the web forums and weekly chat has been outstanding and shown their commitment to improve Openfire to meet the needs of the community.”

 

A huge thank you to Daryl for all of his contributions to the Ignite Realtime community and for providing us with details about this great Openfire success story!

4 Comments Permalink

We are pleased to announce the availability of Openfire 3.5.0 RC1 off of the beta downloads page, along with Openfire Enterprise 3.5.0 RC1 off of the beta plugins page.  The official release is slated for late March or early April, depending on when the official release date of Clearspace 2.0 is.  There are a number of new features and bug fixes in this release.  A couple of the highlights are as follows:

 

New Security Features

 

3.5.0 includes two new improvements to the overall security of Openfire.  One is a new lock out manager, which allows administrators to lock out (disable) accounts, thereby preventing them from logging in.  This can be for a period of time, or "forever".  Another new security feature is a new auditor for actions performed in the admin console.  This will allow you to keep track of what has changed in your server's configuration, and who performed the change.

 

For more information, see: Big Brother In 3.5.0

 

Invisibility

 

3.5.0 includes the ability to connect without sending an available presence.  This provides an easy means for being "invisible" to other XMPP users, and visible specifically to those you intend on speaking to.  This support needs to be built into clients or programs that you might be using to be of direct use, but the capabilities are now available!

 

For more information, see: Playing Casper in 3.5.0

 

Clearspace Integration Improvements

 

Clearspace 2.0 and Openfire 3.5.0 can now work together harmoniously to share users, groups, vcards, presence, and various other functionality.  Not only that, but Clearspace and Openfire will configure their integration in a semi-automatic mode, where you provide a minimal configuration of Openfire and Clearspace and they take care of the rest!  You will see a new option during initial setup where you can choose Clearspace integration that will lead you through the steps.  Please note that Clearspace 2.0 or higher is required for this integration to function properly!

 

For more information, see: Clearspace 2.0 Public Beta

 

Performance Improvements

 

A number of improvements have been made to the overall performance of Openfire in 3.5.0.  An important index was added to one of the database tables that improves roster loading speed by a large degree. The networking framework used for external component connections has also been replaced with MINA, drastically improving the performance of external component connections.

 

Fixed Double-Byte Character Problems

 

3.5.0 includes fixes for double-byte characters not being handled correctly.  This should solve a number of problems with messages that include chinese characters, or other double-byte character encodings.

 

SparkWeb Enhancements

 

SparkWeb 3.5.0 includes a number of reliability improvements, especially with http binding, and also improved support for MUC functionality, such as moderation controls (kick/ban/etc).

 

New Admin Console Look and Feel

 

3.5.0 sports a brand new look and feel for it's administrative console.  Those who have used Clearspace before will be familiar with it, as it's mirrored in concept and general look after Clearspace's administrative console.  The new menu layout is much less cluttered than before, and should involve a lot less scrolling down the page to find what you want.  Warning: Due to changes in the CSS files, and browsers wanting to hold onto CSS files for dear life in their caches, you will likely need to hit shift-reload on your browser when visiting the new admin console.

 

And more!

 

You can view the full changelog here.

You can view the updated documentation (javadocs et al) here.

Plugin updates required for Openfire 3.5.0 are available on the betaplugins page.

The specific plugins that need to be updated are:

  • IM Gateway

  • User Search

  • Enterprise

  • MOTD

  • SIP

 

Happy testing and please let us know of any issues you run into by posting in the  Openfire support forum!

 

Thanks!

-The Openfire Team

20 Comments Permalink

Our original release date for Openfire 3.5.0 was slated for this Thursday, March 6th.  However, it is important that this release be available alongside Clearspace 2.0, whose release date is slated for the end of March or early April.  As a result, we will be holding off the Openfire 3.5.0 release until it can be released at the same time as Clearspace 2.0.  We're very excited about the improvements in the ease of integration between Openfire and Clearspace, as well as the number of other new features and fixes coming in 3.5.0, and we believe it will be worth the wait!  =)  None-the-less, we apologize for the delay!

11 Comments Permalink

We are very pleased to announce that Openfire has breeched one million downloads (not including downloads not from our site)!

 

 

We couldn't have done it without you all, the Ignite Realtime community!  (well of course not, we needed -someone- to download it    )  It's always fun to watch a milestone come and go, and take a moment to reflect, so I thought I would take a little bit to talk about Openfire's history, and even a little about my own personal history with it.

 

When I first found what is now called Openfire, it was somewhere in early 2006.  At the time it was called Jive Messenger and I was the lead developer of PyAIMt and PyICQt and was told that my transports didn't work well with Jive Messenger.  It wasn't long before I 'fell in love with' Jive Messenger and around the middle of 2006, I began work on the IM Gateway plugin.

 

Not long after, I watched Jive Messenger turn into Wildfire, run into a naming conflict, and then turn into Openfire.  As it turned out, Openfire became probably the most appropriate name, as it better reflected the open nature of the product, and was really catchy!

 

So approximately two years after I first became aware of Openfire, we've hit one million downloads!  That's pretty impressive for a server product!  Over those two years we've witnessed so many milestones in the world of XMPP.  One might even call it a "boom time" for XMPP at this point.  So lets all have a drink to Openfire's one millionth download, and to XMPP everywhere!  And also, we at Jive will be having a virtual toast to the Ignite Realtime community, and thank you for all of your involvement!  Happy road to two million!

5 Comments Permalink
1 2 Previous