Skip navigation
All Places > Ignite Realtime Blog > Author: Matt Tucker
1 2 3 Previous Next

Ignite Realtime Blog

43 Posts authored by: Matt Tucker Champion
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 xmpp.org from jabber.org. 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 igniterealtime.org 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.

 

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!

 

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.

 

Matt Tucker

Roadmap Published

Posted by Matt Tucker Champion Dec 20, 2006

We just published a roadmap for the next releases of Wildfire and Spark. One thing you'll notice on the page is a list of the top 10 issues by votes. We make a big effort to prioritize new feature development based on user and customer feedback, so make your voice heard by casting votes!

 

 

Matt Tucker

Better Security With XMPP

Posted by Matt Tucker Champion Dec 17, 2006

Peter St. Andre recently blogged about the Jabber Software Foundation becoming an intermediate certificate authority. In his words:

"What: The ICA enables us to easily and cheaply issue real, RFC3920-aware digital certificates to administrators of Jabber servers http://....
Why: Easily obtainable digital certificates will result in more widespread use of channel encryption among servers and between users and servers, which will make the Jabber network even more safe and secure than it already is."

What's a standards organization doing handing out digital certificates? I don't think Peter is taking enough credit for the vision behind this move. The JSF is attempting something revolutionary: bringing strong security to an open internet-wide protocol. Let's look at the sad state of email security to see why this is important. The global email network is riddled with SPAM -- nine out of ten messages are junk. Email security and encryption technologies like PGP and S/MIME have never taken off, which means that for the vast majority of email, there's no way to know for sure who sent it or to encrypt it. Every user knows to only enter their credit card info on web pages with "https://" in the URL, so how come we accept virtually no security in email? The public IM networks like AOL, MSN and Yahoo are just bad given their own lack encryption support.

 

Providing free certificates is another layer of the XMPP security story and helps make security both easy and ubiquitous. It also shows a commitment by the JSF to not just create protocols, but to see them become widely adopted. The Jabber/XMPP community has always done things a bit differently than other standards organizations. We create standards using an open rather than closed process and use Open Source code to help foster interoperability. The JSF becoming an ICA is another example of doing things in a different and better way.

 

Of course, we're supporting the ICA efforts in Wildfire by doing everything we can to make certificate management as easy as possible. See Gato's latest blog entry for more.

 

We've been doing a lot of work integrating VoIP into Spark using Jingle and SIP (see Thiago's blog post), so of course we wanted to gather ideas from some existing user interfaces. The result? "Ahhh, my eyes hurt!" In my not so humble opinion, we found more people getting softphone UI's wrong rather than right. For your entertainment, I gathered together a visual tour of some of the clients we found.

 

One UI paradigm came up again and again, which is to make the softphone look like a physical object. I can imagine the discussions as this decision was made over and over again by various implementors -- "people know how to use their real phones, so we should make our softphone look like one." Check out the following screenshots:

 

[blog post|http://www.igniterealtime.org/blog/wp-content/uploads/2006/12/officeserv_softpho ne_middle.jpg|officeserv_softphone_middle.jpg][blog post|http://www.igniterealtime.org/blog/wp-content/uploads/2006/12/scrshot_softphone. png|scrshot_softphone.png]

 

How a designer ended up with the examples above is beyond me. They're pretty hideous looking, waste a lot of screen real estate, and worst of all assume that users are so dumb that they need something that looks exactly like a real phone in order to figure out how to use it.

 

That brings us to a related category of UI designs. In these, the designers give up the idea of exactly duplicating a real telephone, but still preserve a tenuous connection by creating softphones that look like devices you could pick up and hold in your hands:

 

[blog post|http://www.igniterealtime.org/blog/wp-content/uploads/2006/12/softphone.png|soft phone.png] [blog post|http://www.igniterealtime.org/blog/wp-content/uploads/2006/12/zebra-softphone.pn g|zebra-softphone.png][blog post|http://www.igniterealtime.org/blog/wp-content/uploads/2006/12/softphone-unlimite d-advance.jpg|softphone-unlimited-advance.jpg][blog post|http://www.igniterealtime.org/blog/wp-content/uploads/2006/12/softphone_gr.jpg|s oftphone_gr.jpg][blog post|http://www.igniterealtime.org/blog/wp-content/uploads/2006/12/sj-softphone.jpg|s j-softphone.jpg][blog post|http://www.igniterealtime.org/blog/wp-content/uploads/2006/12/dialer_v1_big.png| dialer_v1_big.png][blog post|http://www.igniterealtime.org/blog/wp-content/uploads/2006/12/softphone3.jpg|sof tphone3.jpg][blog post|http://www.igniterealtime.org/blog/wp-content/uploads/2006/12/softphone4.png|sof tphone4.png][blog post|http://www.igniterealtime.org/blog/wp-content/uploads/2006/12/softphone5.jpg|sof tphone5.jpg][blog post|http://www.igniterealtime.org/blog/wp-content/uploads/2006/12/xtensoftphone.png| xtensoftphone.png]

 

These designs are a bad idea as well. When you're making a physical device, you create buttons for people to push with their fingers, keep the screen small to hold down costs, etc. Applying these same constraints to software on a computer (with a mouse and large screen) just doesn't make any sense. Why not show a list of people that the user recently called? A text area to type in is a lot faster than clicking buttons on a dialpad, so why not emphasize that? I could go on and on with more examples.

 

Not every VoIP client we found was bad. Skype does an ok job, and we like a lot of what we see in Gizmo. In a few weeks, we'll have the first version of our own softphone in Spark polished enough to start showing screenshots. At that point, we'll welcome feedback on whether we're as off-base with our UI as so many other sofphone creators seem to be.

 

Matt Tucker

Site Slowwwwness

Posted by Matt Tucker Champion Dec 12, 2006

Just wanted to write a quick note that we're aware of the the site slowness issues and the caching problems in the forums. We're working on the caching issues, and a new much more powerful server is on order. Ah, growing pains are fun.

 

Matt Tucker

Java 6 Released

Posted by Matt Tucker Champion Dec 11, 2006

Java 6 has been released (both Wildfire and Spark are built using Java). Normally, the fact that we use Java isn't relevant unless you're building plugins or making customizations to the code. However, the Java 6 release merits a mention for several reasons:

  • This is the first Open Source release of Java. That means that in the near future, you'll see Java 6 ship with many Linux distros. That will make it even easier to get Spark and Wildfire running on Linux.

  • Java 6 support for epoll on Linux fits in nicely with the scalability work we're doing for the next release of Wildfire. Linux users will be able to scale Wildfire to many tens of thousands of connections.

  • There are big improvements to Swing (the user interface library) in Java 6. That means Spark will be faster and prettier with things like font anti-aliasing, much faster re-draws, and quicker startup time.

You can install Java 6 now, or get it automatically bundled with the next releases of Wildfire and Spark.

 

Matt Tucker

Wildfire Product Review

Posted by Matt Tucker Champion Dec 7, 2006

Unix Review just posted a great review of Wildfire and Wildfire Enterprise. From the article:

"Wildfire really impressed me and I find it really hard to come up with a negative when it comes to this great IM server -- perhaps a Debian package would be nice for non-RPM distributions. Installation was a breeze as was setup. Working with the browser-based administrative interface is a joy. In fact, Wildfire is a beautiful, easy to use, configurable, customizable, extensible, and powerful instant messaging server."

The author also does a good job summarizing why companies should adopt XMPP (Jabber) as their IM protocol of choice:

"From a business standpoint, Jabber should be your clear IM choice. Because Jabber is an open protocol, it doesn't belong to anyone in particular, so there is no single company driving its destiny. Your business won't get locked down by proprietary formats. Jabber also uses a decentralized approach so the system is more robust. Best of all, any company can run its own private, secure, standards compliant, Jabber instant messaging server for little or no cost for the software."

 

Matt Tucker

Wildfire Integration Day

Posted by Matt Tucker Champion Dec 4, 2006

Two weeks ago (Friday) we had the first monthly Integration Day. Integration Day is when the entire Jive Software engineering team gathers to work on projects to integrate Wildfire and Spark with our other products (in this case, the upcoming product Clearspace). Bagels, pizza, and beer were enjoyed as well -- it was all very much in the spirit of some of our other dev team jamming days, Bug Day, and Sparkplug Day.

 

We considered two different architectures for the base integration:

  1. Wildfire connects to Clearspace using SOAP web services.

  2. Clearspace connects to Wildfire as an external component.

After much discussion, we settled on making Clearspace connect as a component. That means that Clearspace connects over XMPP to Wildfire and then exists as "clearspace.example.com" (if the XMPP server was "example.com"). Just being connected as an external component doesn't buy a whole lot, so the next step was to build out some real integration code. The first step was to share presence data. We did so using two new Wildfire ad-hoc commands. The first returns a list of all current online presence information for users in the server. The second registers the external component to get a copy of all further presence changes. We're working on documenting these commands for the next release of Wildfire. With both in place -- voila! -- Clearspace knows the real-time presence status for every user in the system. I have a feeling this type of presence integration will be very useful to a lot of applications and not just ours. It's much more elegant than using the presence plugin, for example. The second integration component was to expose all Clearspace SOAP web services through XMPP ad-hoc commands. One of the Clearspace engineers (AJ) was able to do this with only a small amount of code using some clever XFire hacking.

 

These base integrations unlocked a lot of other feature developments, which we made good progress on. However, the next Integration Day is later this month so I'll wait until then to provide some more details, perhaps with some screenshots.

 

The sad reality is that the latest official release of XIFF (2.0 beta 2) is over a year old.  However, the project is far from dead. Regular forum readers know that Nick Velloff from Lymabean has bee doing active XIFF development and a new release should be coming soon.

 

As I'm writing this entry, we're in the last days before launching igniterealtime and I'm waxing nostalgic about the project that started all of our real-time efforts, Smack. It was four years ago that I looked around for a good Java XMPP client library and came up short. There were some other libraries out there, but most of them assumed that you already knew the in's and out's of the protocol and I was a full-on XMPP noob at the time. The goal for Smack simple: create an API easy enough to use that even someone  like me could figure it out.

 

We've stuck with that focus in each subsequent Smack release, even as the functionality has grown richer and richer. In between torrid work on the next Wildfire and Spark releases, we've slipped in work on Smack 3.0 (partially with the generous help of community members Francisco and Gabriel). Some of the major changes that are coming:

  • Uses JDK 1.5 for cleaner syntax and simplified code.

  • Support for re-using an XMPPConnection when the TCP/IP connection fails, including an auto-reconnect feature.

  • Rounded out support of the XMPP RFC's through better error packet handling and privacy lists support.

  • Ability to listen for new chat requests, which I felt was one of the major remaining design flaws in the library (thanks Alex!).

  • Tons of bug fixes.

There's no planned release date yet, but we've been using the latest code in Spark for quite some time.

 

So, a taste for where it all started and where it's going. But the really interesting part for me is where Smack is being used. Have an interesting application of Smack? Please post a comment to tell us about it!

 

Filter Blog

By date: By tag: