Skip navigation
All Places > Ignite Realtime Blog > 2007 > January

! if! Wildfire has been selected as a finalist for this year's CODiE awards in the Best Communications Solution category. We'll find out on April 17 just how much the judges like the most cutting-edge Open Source communications server on the market. Going through the judging process for awards can be time consuming, but they're a great validation for the project. Of course, don't forget about the  Open Source Reader's Choice voting -- we're just nine votes away from first place!

!!Ear lier this week, I gave a talk at the Internet Telephony conference about next generation unified communication. You can check out the slides. A few caveats:

  • I didn't pick the title of the talk and the ugly slide template was required.

  • There's a lot of context missing without me talking, but at least you'll get the gist.

The telcom industry seems to be moving full speed ahead towards unified communications (I see it as the convergence of voice with other communication channels). Most of the vendors talked about presence as an important concept and were doing some amount of text messaging, chiefly through Microsoft LCS integration.


As many of you already know from our roadmap, we've been doing a ton of work on voice, which will land in the next releases. So, it was great for me to get the telcom perspective and imagine how we'll all meet in the middle with feature sets. Personally, I'm pretty excited about all the possibilities.

Matt Tucker

Some bad news on naming

Posted by Matt Tucker Champion Jan 22, 2007

Starting in 2003, we used to call our RTC server "Jive Messenger" -- very clear, but not very exciting, and not much of a brand in and of itself. So we decided to rename in 2005. We went through a long process (including going out to the community) and ultimately ended up with "Wildfire" -- everyone loved the name and it worked well with the product.


Unfortunately, we recently hit a snag. Even though we performed a trademark search at the time we chose the name, we were recently asked to end the usage by a company who sees their product as similar. Their original trademark was for a protocol that supports peer-to-peer file sharing -- it was close, but we were pretty sure it wouldn't be perceived as an issue. Unfortunately, this same company expanded their usage afterwards to include other forms of real-time communication. And now they believe that our use of Wildfire is infringing on their trademark.


As you can imagine, it's been incredibly frustrating. We didn't see it as a confusing mark, but they weren't budging, and we didn't want to get into a costly legal battle that we likely wouldn't win. It's also an exceedingly expensive situation, since we've invested so much in the brand. In hindsight, we could have done more homework on the name, and could have involved more lawyers. Painful lesson learned.


After exhausting the possibility of keeping the Wildfire name we've now started working on a new name for the project. We're still researching and brainstorming, but getting your thoughts early in the process is very helpful. And this time we'll be more careful (read "paranoid") as we search for a new name for Wildfire. You'll probably see some names that have absolutely no infringement potential: Getabubazz? Havofrindia?


We don't have an exact time frame for the change yet, but we're going to keep an open process and I'll provide status updates in the forums. This is a situation that I never wanted or imagined and several of us here at Jive have had sleepless nights over the problem.  Still, I'm confident that we'll get through it and look back on all of this as just a blip on the quest to build the leading Open Source real-time collaboration server on the market.


Today, the the Jabber Software Foundation announced that it's now the XMPP Standards Foundation. Already, a lot of content has been moved to from The change is symbolic of much that's happening with the protocol:

  • Explosive growth -- Almost every week a new network or product seems to announce XMPP support (although we're all still waiting for another major consumer IM network to follow Google's lead). The XMPP standard is also rapidly evolving in areas like VoIP with Jingle and advanced presence with Personal Eventing via Pubsub. We've seen the growth trend at as well -- we're nearing 1 million downloads of Wildfire and on the verge of making our most significant set of product releases ever.

  • The slow death of SIMPLE -- two years ago the story was about how the SIMPLE protocol was winning the real-time standards war against XMPP. Now, only Microsoft is left beating the SIMPLE drum and that complicated, bloated mess of a protocol is fading into irrelevance. Microsoft is still the most important player in the corporate IM world, but at least we don't all have to pretend anymore that they're pursuing an open protocol. XMPP is the only way to have open federation, which is why products like Lotus are adding support.

  • Open for business -- Jabber started as an Open Source project and the Jabber Software Foundation began its life in that tradition. It wasn't that long ago that the organization didn't have a reputation for being friendly to companies looking to adopt the protocol. All that's changed now and the JSF to XSF name change re-enforces  that trend. I'm proud to be part of an organization that's pushing the boundaries for how Open Source and commercial interests work together to develop an open protocol.

Last year, a blog entry claiming that 2006 would be the "year of XMPP" got a fair amount of circulation. Indeed, a lot of great stuff happened last year, but 2007 is truly the year we'll see everything come together for XMPP.


One of the great things about using open source software is that if you want to alter the way an application works or add a feature you can jump right into the code and make all the changes you want. A down side to all this freedom is that if you make a change to the source and then awhile later a new version of the software comes out, you have to merge your changes in with the new version. Depending on the sort of changes you've made, this can be a real nightmare. One increasingly popular way to avoid this sort of hassle is by using plugins. What is a plugin? Wikipedia provides a pretty good description: "A plugin (or plug-in) is a computer program that interacts with a main (or host) application to provide a certain, usually very specific, function on-demand." Some programs that you might have heard of or be familiar with that use plugins are Elipse, Firefox and of course Wildfire and Spark.


This is the first in a series of articles that will explore what can be accomplished with the use of plugins for both Wildfire and Spark. Initially, I'll focus on Wildfire plugins, beginning with a couple of pointers to get the plugin development environment setup. Then over the course of the following articles, I'll discuss some of the more commonly used API's, develop a plugin or two and maybe even get a Spark plugin to talk to a Wildfire plugin.


Now, let's get started!


Download the Wildfire source


This one may seem like a no-brainer to some, but it's not entirely obvious that you need the Wildfire source in order to develop plugins. As an added bonus, included along with the Wildfire source is the source to all the existing open source plugins. I don't know about you, but when starting in an unfamiliar development I really appreciate having access to sample code that I can reference.


Kick the tires


Now that you have the source, work your way down to the src/plugins directory and look at how some of the plugins are put together in terms of both their structure and the code itself. Even though the plugins all share the same basic structure, they vary greatly in complexity and the API's that they use.  The registration plugin is probably the most basic, while the gateway plugin is by far the most complex.


Check out the documentation


As you may have noticed, the Wildfire source also contains a great deal of documentation. One of things I like to do is to bookmark the index.html page (located in documentation/docs directory) so that I can quick access the Plugin Developer Guide and Wildfire JavaDocs. And if you haven't already, I strongly recommend you read over the "Plugin Developer Guide" and "Building the Source" how-to's. There are two additional items not mentioned in either of these guides that will help speed up your plugin development. One, instead of executing the 'ant plugins' command which builds and deploys all the plugins use the 'ant -Dplugin=your_plugin plugin' command instead (replacing 'your_plugin' with the one plugin you want to build) which will only build and deploy the plugin you specified. And two, during the plugin development configure and use the wildfire-dev startup script (located in the target/wildfire/bin directory) to startup Wildfire. By using the script instead of the 'ant run' command you can edit your plugin source files and see the changes without having to redeploy your plugin. A potential gotcha to using this script when editing .jsp files is that you need to have a empty WEB-INF directory in the your_plugin/src/web directory. If the WEB-INF directory is not present your plugin will still load and you'll be able to view its .jsp pages but any changes you make to the source will not be re-compiled and you'll fill up your error log with  JasperExceptions.


All right, so now that we have some of basics out of the way, next time we'll be able to jump right in to some code. My hope is that this series of articles will be as beneficial and interactive as possible.  If there are any additional topics you'd like me to cover or if you have further questions regarding something I've written or indicated, please leave a comment or send me an email.


See you on the forums,

Ryan, aka ryang


Parking Lot Presence

Posted by greg Jan 12, 2007

!!About a month ago Thiago flew from his home in Brazil to Portland for an in-person visit with the rest of the team here at Jive. When Matt and I went out to the airport to pick him up we noticed long lines of fancy new vehicle presence sensors on the ceiling, one for each short-term parking slot.


Beyond simply sensing the car's presence the device includes bright LEDs that display blue when vacant and red when occupied. Since the device is mounted on the ceiling it is visible from several aisles away and can help guide drivers to available parking slots. After a little searching I came across a presentation by Dan Brame that provides an overview of the PDX parking technology. It turns out that the sensors and lights are just the beginning of a system that is designed to direct drivers to available parking slots efficiently without the need to drive up and down aisles looking for that elusive open spot. Apparently, innovation in the parking lot is happening all over. One of the Clearspace engineers, Aaron, recently came across a blog post about Santa Monica's real-time parking availability maps as well.


!!Presence is a powerful concept, and it isn't limited to people. Network devices, parking lot sensors, computers, etc., can all have presence that can be used to make systems more effective. But, as the example above shows, a physical representation of presence, such as a desktop signal light, can be very helpful in some situations. The world is just scratching the surface of this powerful concept. From something as straight-forward as rich presence based on your calendar to advanced sensor networks adapting to topological changes we'll continue to see new value created by new presence detection and inference mechanisms as well as innovative uses of the presence data.

With all the Apple news recently, as well as several new employees using Macs (including myself), I thought I'd write up a little update on what Jive is doing to improve how our products run on the Mac. There are a couple of areas where we're making big strides forward:



Installation Experience


Most Mac applications are distributed in disk image (.dmg) files, and some are installed from the .dmg via an installer package (.pkg) file. Disk images alone are used for standalone apps that can be installed by dropping them where you want them, while installer packages are used for more complex apps that install lots of support files.


The Spark dmg file now includes some spiffy background art based on the Spark logo, as well as a symlink to the applications folder so installing really is just drag -> drop; no need to dig around in the filesystem finding the applications folder first.


Wildfire is a bit more complex. The new Wildfire.pkg file creates an unprivileged user called Wildfire, so that the application can run in a "sandbox" much as apache and other system services do. It also installs the next two improvements on the list...


Launchd and Wildfire


Launchd is Apple's new replacement for init, rc, inetd, xinetd, atd, crond, watchdogd, and SystemStarter. As of Mac OS X 10.4 it's the recommended way for services like Wildfire to run, so I have created a launch daemon file for Wildfire. This allows for all sorts of customization for the savvy system administrator, including easily imposing resource limits, automating startup and shutdown, and other handy things previously spread across the system in various configuration files. For people who don't want to spend their time tweaking XML files, there's a new feature of Wildfire that makes controlling this even easier...


Wildfire System Preference Pane


The Wildfire prefpane provides a simple interface for starting and stopping Wildfire, configuring whether Wildfire will start when the system starts up, and accessing the administration page.


Spark Fixes


Tuesday morning we had a meeting where we brainstormed a whole bunch of fixes and improvements to Spark, ranging from renaming preferences in the Mac version (Toast? We use Growl in these parts!), to fixing keyboard shortcuts (command-w is on the list), to making sure that windows gain focus correctly when new messages are added. This sort of polishing should make Spark much nicer to use, even without some of the larger things that we're looking at, such as Address Book integration.


Matt Tucker

Vote for Wildfire

Posted by Matt Tucker Champion Jan 8, 2007

Wildfire is up for an Enterprise Open Source Reader's Choice Award in the "Best Open Source Product" category. As you can see from the current vote tally below, it's time to get busy with the votes. So, please take a moment to go cast your vote for Wildfire!


Update l XIFF 3 beta

Posted by flashgrand Jan 5, 2007

Thanks to everyone for their continued interest in the new XIFF library. The release for the XIFF 3 Beta version in Actionscript 3 is still on its way.


In addition to the Actionscript 3 port, the new library was developed with AS 3.0 best practices in mind and will contain a few new features that will assist during project development.


New Features

1. Support for binary socket connection.

2. Support has been added to handle the separate deliveries of packets greater than 1500 bytes. This is generally a trait of large rosters.

3. All events and value objects are strong typed. I know you will agree that this will make everyones life just a little bit easier.

4. Support for Flex data binding.

5. Mixins have been eliminated.

6. Many, many bug fixes.


Outstanding Items

1. Update to EX4.

2. Documentation.


The library has been tested by me with both Wildfire 3 and a Jabber XCP servers. Check out a demo here:

Beta XIFF GUI (currently connecting to Jabber XCP)


Nick Velloff

Velloff Blog

$588 billion? Are you serious?

Posted by greg Jan 2, 2007

At Jive there are quite a few "Battlestar Galactica" fans, but I had not watched the show before this weekend. When my wife received the season one DVD set over the holidays, it was a chance to find out what all the buzz was about. The show is awesome so far, but one scene in particular caught my attention. During the first episode the commander of the ship rehearses a speech as he wanders the corridors. He keeps repeating the first couple of sentences of his monologue, but is consistently interrupted before getting any further. As he settles into giving his speech it becomes clear that all of those interruptions distracted him from his plans and he ends up giving a completely different speech. In our own daily work lives, interruptions can be very costly. CNET recently reported on research by Basex that found that interruptions could be costing U.S. businesses up to $588 billion per year.


What does this have to do with real-time collaboration? Instantaneous human interaction, whether in person or through a medium such as IM, has the potential for interruptions which lower productivity. At the same time, some interruptions are critical to collaboration and creativity. Coming up with tactics for managing these interruptions in a way that balances the good and and bad aspects can greatly improve all of our effectiveness. Matt provided some tips last year, including some of the ideas below.


!!One way to manage interruptions is through the active management of one's presence. At Jive, if you set your presence to "Do Not Disturb", most people will avoid messaging you unless it is critical. When you really need focused time, "Do Not Disturb" can be invaluable. However, there are still in-person interruptions that can occur since your presence cannot be seen as people walk up to your desk. We recognized this problem internally and have added USB LED signal lights to some workstations (the lights are expensive). A Sparkplug then changes the color of the light based on the user's presence. For example, when the presence is set to "Do Not Disturb" the light automatically changes to red as a signal to others. This system works well for people who actively manage their presence, but not for those of us who routinely forget to change our presence.



!!Automat ic presence information synchronization is a great way to help solve the pain of manually changing presence. Wildfire and Spark can be integrated with Asterisk so that when someone is on the phone, their presence is automatically updated to "On the phone" -- this works great with the presence lights. A future source of presence information will be Outlook calendars. Automatically changing presence to "In a meeting" will help others see whether you're available and save them time tracking you down. The (somewhat blurry) picture at right shows two presence lights in action -- the one in the foreground is green, while the one in the distance is red. Next week I'll package up the Spark plugin that powers the lights and release it in the forums for anyone that's interested.


Achieving greater productivity through the reduction of interruptions is beneficial for all of us. We can experience less frustration and be more effective without giving anything up. All it takes is more consistent use of presence to indicate availability -- that requires both accurate (and automatic) presence information as well as a culture of respect for presence status so that "Do Not Disturb" has teeth. Let's work together to shave a few billion dollars off of the waste that unnecessary interruptions generate.

Matt Tucker

Happy New Year!

Posted by Matt Tucker Champion Jan 1, 2007

Happy New Year to everyone in the Wildfire, Spark and Smack community! 2006 was a great year for the projects and we have a lot in store for 2007.


The concept of transports is what brought me into the world of XMPP in the first place.  At the time, I was tired of having to recall my usernames and passwords for AIM, ICQ, MSN, and Yahoo every time I switched to a new machine or IM client.  The ability to store all of this information with a central account, on a server that I controlled, appealed to me on many levels.  Upon setting up my own server and getting a couple of transports running, I discovered that XMPP itself is quite an interesting protocol.  I wrote my own client soon after, and eventually got involved with writing my own transports for AIM and ICQ (PyAIMt and PyICQt, respectively).


Now, in the process of writing those transports, I continuously ran into frustrating scenarios where the transport just did not have enough access to the user's roster or session to do anything in a smooth manner.  Some proposals came about, such as the unaccepted roster subsync proposal, and roster item exchange.  The latter showed up, unfortunately, after it became a bit of a pain to incorporate its functionality into the existing code.  Instead of sending roster items individually, the goal would be to gather them all up and send them in one big packet.  The other bigger problem was that both this way and the old way would have had to continue being supported because I never did find a client that actually supported roster item exchange properly.


Unfortunately, all of the issues that come up affect end users, not administrators.  I'm much more willing to inconvenience administrators than I am end users.    For example, without roster item exchange, upon registering with a transport, a user gets flooded with subscription requests for every contact on their contact list on the other service.  Now I don't know about you, but for me that's a lot of contacts.  On top of that, the transport has to try to keep track of what items the XMPP user already knows about.  It's not hard for this to get out of sync.


So Matt came to me at one point and asked me to write a plugin for Wildfire that would perform the services of the external IM transports, but be much easier to set up and work more smoothly.  At first I balked at the concept of taking on yet another project.  However, the opportunity to have an excuse to learn Java and being able to use internals to work around some of the bigger issues I get irritated with in my python based transports by using Wildfire internals was very intriguing.  Since then I've come to gain a respect for, and even enjoyment of, Java.  I adore the slew of well written tools, the wonderful IntelliJ IDEA software, and the wealth of documentation and libraries available for it.  I'm quite pleased with what I've been able to do with the plugin that I was not able to do before.


That said, the unfortunate thing about working with non-open source protocols is that:

  1. The protocols change without warning

  2. The owners of the protocols don't typically want you there in the first place

  3. Libraries written to handle the protocols are often incomplete

I've never really understood the resistance to others implementing and connecting to your service from non-official clients.  I happen to believe in letting folk use whatever they want to use to communicate with each other.  This means not only that I believe XMPP users should be able to communicate with AIM/ICQ/MSN/Yahoo/etc users using their own XMPP clients, but also that AIM/ICQ/MSN/Yahoo/etc users should be able to communicate with XMPP users using -their- own clients.  I've never been one to quest for folk to "convert" to another protocol.   So this is part of why I enjoy working with transports so much.


The IM Gateway plugin will continue to improve, on to version 1.0 and on further from there.  I will try to improve the world of transports in general via new concepts (probably in the form of new XEPs).  I will not forsake my external transports in the process as they also serve wonderful purposes.   All in all, I'm pleased with how the future of things is looking and I can only hope others are as well.


I will be posting more here in the future as development progresses, both about the IM Gateway plugin, and about new concepts in the land of XMPP transports.  As for the plugin itself, you can download the beta releases of it from Wildfire beta plugin page.  I would also like to invite you to visit the IM Gateway Support forum and post any questions or concerns!

Filter Blog

By date: By tag: