Gato and I are sitting together drinking beers and hacking on Ignite code. After a hiatus (too long), we're both back to working on Smack and Openfire weekly. As I'm writing this, Gato is doing some super low level Java debugging to figure out a strange XML parsing error that we're seeing when running the Smack test cases. Assuming we get to the bottom of the problem, we plan to package up and release a new beta release of Smack. It includes lots of great improvements, but I'll leave the details for the next blog post. We have several goals around our weekly hackathons:

1. Jump start software releases -- it's time to get more regular releases of all the projects going again.
2. Recruit and empower community leaders -- there's already a large number of people in the Ignite community doing some amazing work on the code. Now it's time to equip them with the tools to be as effective as possible and to let them take on more explicit leadership roles.
3. Have some fun -- hence the beer

We're looking forward to demonstrating progress and to keeping the Ignite projects at the forefront of the XMPP world.

I use Openfire and SparkWeb everyday and recently starting evaluating Clearspace to power the community I am building for my wife's education consultancy (www.inspiredfutures.co.uk). As I had limited computing power and memory to work with on my hosted server, it became expedient that I needed to integrate all three products under the same web server and Java JVM.

The first thing I did was to make an openfire plugin out of Clearspace

The next thing I did was to enable SparkWeb display an HTML page from its chat container

The result is what you see above and I am very pleased with it (chuffed as we say in the UK). The benefits of integrating Openfire and Clearspace has already been mentioned here . Adding SparkWeb to that combination in order to have realtime messaging, desktop sharing, Red5 audio/video calling and a SIP phone makes a compelling case for me to use Clearspace

I have reservations about real-time integration with web applications that use the MVC model based on Stuts like Clearspace or even PHP applications like SugarCRM. Even Salesforce.com also falls into the same group because they all build their UI on the server and everytime the user does anything that requires a server fetch, the screen goes all blank while you wait for the whole page to be rebuilt from server-side Java code.

Putting a softphone or an IM client as a widget in these applications requires constant connect/disconnect cycles as the user moves from page to page. It reminds me of my attempt to build a real-time application on an Apple iPhone and a softphone in Salesforce.com. What we need is to be able to keep our widgets UI resident on the client as well as the user session in the plugin on the server. I am curious to see how Jive Software implements the realtime widgets in Clearspace.

In the meantime, I am happy to make SparkWeb my container for real-time web applications as I am getting biased towards Adobe's open-source Flex as my de-facto web client application development platform. I learnt a lot from studying the SparkWeb code and I am planing on developing some Clearspace widgets that use SparkWeb's features through the Javascript External Interface to make the integration complete.

If you want to use SparkWeb as a container for your web applications as I have done, pick up the latest version of the Red5 plugin from here. Copy and edit index.html. Change the httpLabel and httpURL parameters to your preference.

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!

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.

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.

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

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.

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.

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!