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

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.

Important, Seriously, Pay Attention, Read This

Big Connection Manager Improvements

Ok Fine, Where Do I Get It?

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.

• 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.

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!

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!

In Openfire 3.5.0, we have added two new features to address security concerns! One of these features is security auditing. We've had packet auditing in Openfire for quite some time now, but that only addresses communication amongst users of your Openfire server. What the security auditing functionality provides is logging of administrative activities performed via the Admin Console. Any action you perform that changes the server's configuration, adds, removes, or edits users and groups, or any number of things, will be logged into the security auditor database. On top of that, we've implemented this via provider functionality just like the user providers. What this means is that if you have a custom place you'd like to be logging audit events, or perhaps wanted to write some sort of sms event triggering implementation, you can do that and plug it into the existing infrastructure.

Beyond the security auditing, we have implemented the ability to lock out (disable) accounts. By default, you can lock out accounts for certain periods of time, use delayed starts, or lock them out until manually unlocked. You will find the option to lock out a user while viewing their account in the admin console. Just like with the security auditor, the implementation uses a provider, so that you can implement whatever source you might have for disabled accounts.

The APIs should be pretty flexible and enable developers to build whatever solutions they might need around these two concepts! I will be posting some more details in the Openfire Dev forum in the near future to go over some of the details and other API improvements. We hope that you will enjoy the new functionality when 3.5.0 is released!

One of the things you may have noticed that appeared in the 3.4.3 release of Openfire is a couple of new installers, and some improvements to existing installers. Oddly enough, building installers can be one of the more difficult tasks a developer has. Simply putting out a tarball or zip file is easy, but it's not exactly the most pleasant thing to deal with from an administrator perspective. In the process of creating installers, you often find yourself fighting with differing standards between OS distributions, or different architectures altogether. That said, typically once you have created the installer, there's not much to do with it after, so it's generally a one time cost, so to speak, and the benefits far outweigh the time spent!

In an effort to make Openfire as easy to install as possible, we added official Debian and Solaris packages. Yes, I am aware the Solaris package is listed under Linux right now, but please ignore that for now. Are we stopping there? Not really. I'm not yet sure what other OS's we might be providing packages for at this point. FreeBSD is about the only other one I've seen a request for and there's a well maintained port (net-im/openfire) of Openfire already.

What we are investigating now is providing hosted repositories for the packages. Specifically, I'm looking at a Yum and APT repository at the moment. This would allow system administrators to point their repository configs at our repositories and be able to easily keep up to date. We are still working out the logistics of this, so stay tuned!

We're also investigating getting Openfire into more distributions. In other words, instead of having to come to our site to get Openfire, perhaps you could install it from a central Debian repository, or an extras cd, or something of that nature. There are a couple of possibilities in the works on that front, and a couple more I'd like to pursue.

So hopefully in the near future, it will be as easy as ever to get rolling with Openfire!

You may or may not already be aware that I have been a full time member of the Jive family for a couple of weeks now! It's been quite interesting to see how different it is from my previous job in a university setting. It's been a lot of fun already and it's really exciting to have turned my favorite hobby into a career. =) My coworkers are great and I almost find myself wondering why I didn't do this earlier.

So what am I going to be doing? Well, the development of the IM Gateway plugin is part of my job now. We'll be setting solid goals and release dates instead of it being dependent entirely on my free time. That and Openfire are my main focuses. I'm really excited about playing a more direct role in Openfire development! One of my first tasks will be to improve the unix installers for Openfire. They have been lacking love for a while now and I have a strong unix background to bring to the table. In one of the next releases of Openfire we'll have improved packages, unix scripts, and better support for more operating system distributions. Overall, good things to come! =)

You may have heard that I have taken over as lead developer of Spark. It's been a long time since I have been involved in client development and I actually miss it. My very first XMPP related project was a client. Now, as you've heard from the Ignite Realtime post preceding this one, Spark is a low priority. My focus with it in terms of work with Jive is bug fixes, maintenance, and paying customer requirements. Beyond that, I'll likely be working on it on my own time when I need a change of pace. I am a Mac user primarily, so you may see more Mac focused fixes at first. If nothing else I'm going to make sure Spark is something I enjoy using, which coincides to a lot of things that the community has reported/requested anyway. I highly encourage folk who are interested to submit patches! The only caveat is that for patches of any size, I'll need you to sign contributor agreements, if you haven't already.

Now, since I'm involved in more than just the IM Gateway plugin now, I can't keep up with the forums as much as I did before. I try to spend some time each day looking over the forums, but with more than just the single forum, it's too much to keep up with entirely. Dawn is working hard on coming up with good ways to involve the community more and try to make sure things don't get missed! She has been speaking on this in the Jive Lounge, so please visit the lounge and contribute if you have some thoughts!

Anyway, I wanted to make sure folk understood that my role has changed and wave hi from within Jive! =) Any questions?