Skip navigation
All Places > Ignite Realtime Blog > 2007 > April
2007
Matt Tucker

Openfire Powering Web 2.0

Posted by Matt Tucker Champion Apr 30, 2007

I've recently run into a number of innovative sites and products that use Openfire.

 

!http://www.igniterealtime.org/blog/wp-content/uploads/2007/04/imified.gif![IMifi ed|http://www.imified.com/] provides tools like task management, reminders and todo's through IM bots on AIM, MSN, and XMPP/GTalk. They've just released an API that will make it easy to write bots that work across all major IM networks. Openfire powers their XMPP back-end.

!http://www.igniterealtime.org/blog/wp-content/uploads/2007/04/mosoto.gif![Mosoto |http://www.mosoto.com/] is a real-time collaboration application for Facebook that includes chat along with file and music sharing. They're one of the premier implementors of the Facebook API and have a slick Flash client UI. The service is now in Alpha, but should mature and grow quickly (especially given the size of the Facebook userbase). They use both Openfire and the XIFF Flash API.

 

!http://www.igniterealtime.org/blog/wp-content/uploads/2007/04/justintv.gif!Final ly, we were told at the Web 2.0 conference that the chat feature on Justin.tv is powered by Openfire. I haven't had a chance to to verify that yet, but if true, it's cool that we're part of such an interesting social experiment. If you haven't seen the site yet, Justin wears a portable camera 24x7 that streams a live video feed to the website. I personally can't imagine broadcasting my life, but I have to respect the social commentary. In a world where we're always connected and available through cellphones and IM, this guy is really always connected and available... to the entire world.

 

These three examples are part of a broader trend: I think that XMPP will become a critical piece of infrastructure for a large number of next-generation web efforts, including Google. Recent protocol advances like BOSH (XMPP for web pages), Jingle (voice and video) and PEP (advanced presence features) will only further help drive adoption.

Matt Tucker

On the Release Train

Posted by Matt Tucker Champion Apr 22, 2007

The engineering team at Jive Software is growing fast (btw, we're hiring!). I thought it might be interesting to talk about some of the engineering process changes we're making to cope with that growth, especially since they directly affect product releases. First, a bit of history. We've always had a fairly agile development process -- lots of iterations, tools like unit tests and continuous integration, etc. But, we've consistently had a lot of pain around our current process:

* Not enough time for QA* . It's always scheduled, but gets squeezed due to lack of time. For example, the "official" QA time period for the Spark 2.5.0 release got crunched down to almost nothing.
* Stress when we don't need it* . The stress is caused by having to cram a ton of work into a short period of time to make internally set product release dates. It's also caused by scheduling extra features into releases at the last minute and by having to do emergency patch releases due to bugs we missed. We like working really hard, but there should be a way to do that without excessive stress.
* Unpredictable release dates* . The bigger a release is, the harder it is to make accurate work effort estimates. That means that dates slip and that it's hard to communicate to the outside world exactly when a release will ship.

So, there are some clear problems that we want to fix. The trick for us was to come up with a process that fixes those problems but that's still light-weight enough to avoid a huge administrative burden. We're now experimenting with a strict release train model for Spark and Smack. Assuming it goes well, the same model will be applied across all our products, including Clearspace. A visual summary of the model is below (click the image for a larger version):

[Clearspace|http://www.igniterealtime.org/blog/wp-content/uploads/2007/04/train.png|train_sm all.png]

 

The key points to this model:

  • We put out a new release every three weeks (although each release will have gone through a nine week process total).

  • Three weeks before each development cycle is reserved for product management; three weeks after each development cycle is reserved for QA. But notice that all three processes are all happening at the same time.

There are all sorts of subtleties to the system like how to deal with new features that take more than three weeks of engineering time, but so far everything is going quite well.

 

The start of the three week cycle is always on a Monday, and we have a big meeting to determine exactly which features will go into the release. Product management has already done the work of prioritizing the features so we just need to choose exactly what we're going to work on and come up with the plan about how to get it done over the next three weeks. On the second and third Mondays during each cycle we go through more detailed updates than in our SCRUM meetings to see what's on track and what's not.

 

At the end of the cycle, we:

  • Do the product release coming out of QA on Thursday.

  • On Friday, finish all development and create a branch ("spark_2_5_2_branch" for example).

  • Switch the builds in our continuous integration environment, TeamCity. The new branch becomes the "stable" release of the product and trunk becomes "development".

  • Release a beta version out of the new branch. In other words, the world generally always sees a stable official product release and a beta release that will become official in three weeks.

There's way more that I could talk about with this process (including some of the potential drawbacks), but I'll save that for future blog entries. Things we're jazzed about so far include solid release dates, having a better process in place to deal with new feature requests and bug reports, more stable quality in each release, and always having a place to check in new feature development (trunk). We're still early on in the new system, but we'll all know how exactly how well this works in the next two months. Of course, we'd love your feedback as time goes on about how well you think we're doing.

 

As the lead developer of the web-based version of a voice trading system used world-wide by some of the largest financial organizations, I have learned one or two things about web-based VoIP applications. When we designed our trading application, web-based VoIP was not ready for the 99% reliability and quality demanded for financial transactions. We therefore decided to keep the voice on a regular telephone (POTS) and used the web browser to handle the real-time signaling and associated data using a push method called pushlet.

 

My work on the Red5 plugin for Openfire is a personal attempt to investigate alternative communication technologies and get involved in the open source community. I could not have picked a better place than the Igniterealtime community. It will be interesting to see what happens when Adobe release their own VoIP enabled Flash client, but until then Flash and Red5 in my opinion is still the best way to do web-based VoIP applications.

 

The telephone landscape is changing. It's less about exclusive voice communication and more about real-time collaboration where voice is just one of the many communication channels used to do effective collaboration. I believe presence is a very important ingredient that brings intelligence to finding the right channel to communicate with one or many contacts in real time. This is a vision that I share with Jive Software and that why I endorse and work with Openfire on a personal basis. The plugin approach on both server and client is a very smart idea and has enabled me to integrate Flash and Red5 with Spark and Openfire with little or no effort. Implementing HTTP-binding in Openfire was icing on the cake and enabled me to add audio and video to a web-based client like JWChat with relative ease.

 

This brings me to the purpose of this blog.

 

At the moment, Spark users get a choice of SIP, Jingle and Red5 for voice. These features enable Spark to make calls to SIP phones, XMPP users and web-based XMPP users. SparkWeb does not do VOIP yet, but that will change when Jingle supports a web-compatible transport.

 

Web-based XMPP users could not call SIP phones until now.

 

I have designed a gateway (audio bridge) which converts red5 calls to and from SIP. I have now implemented a version for Windows XP/2k3 using Asteriskwin32. The basic engine is an ActiveX component written in Visual Basic and the source code is open. To solve the problem of transcoding the proprietary Nellymoser codec to SIP, I have used 8 pairs of virtual soundcards provided by a commercial product called VAC (Virtual Audio cable). It is very popular and has been used on other projects to bridge Skype for example.

 

I now have tight integration between Openfire, Red5 and Asterisk and this has lead to a new version of the Red5 plugin which can control the red5Gateway and implement some interesting ideas. For example, the gateway makes it possible to make every user and group JID become a public SIP address. The gateway will route and convert all SIP calls for user@domain.com to a red5 call. In reverse, if you make a Red5 call to an extension nnnnnn, the gateway will convert it to SIP and pass it on to your configured SIP service provider to route. In the case of group@example, Asterisk is used to hold the caller in a queue while every group member is called until someone answers.

Red5 gateway support is disabled by default on the Red5 plugin, as it is an optional component and is not part of the red5.war file. I am in the process of creating a hosted server to demo it over the next few weeks. If your Openfire runs on Windows and you are interested in trying it before then, send me an email and I will send you the link and documentation as soon as I finish writing it.

 

In the meantime, enjoy the latest version of the red5 plugin 0.0.7 which is now compatible with Openfire 3.3.0 and Spark 2.5.1. It has the latest Red5 server code: 0.6RC3. I tried to downgrade it to java5, but it was incompatible with Openfire, so I gave up trying :(. I have added support for viewing vcard avatars. I will add the ability to upload images in the next release so you will need Spark to upload the photographs/images for now. As I use jwchat5 myself, I have made the chat UI much like Pandion style, which I like. I only got one bug report from the previous release and have fixed it.

 

A big thanks to everyone at Igniterealtime, especially the folks at Jive who have added Red5 support duties to their already busy day jobs.

 

As always, all feedback positive or negative helps to motivate an open-source development and influence product design. The current version 0.0.7 is still far from 1.0.0, so please keep the comments coming.

 

-dele

 

Spark Skinning Update

Posted by greg Apr 13, 2007

!http://www.jivesoftware.com/skin/images/spark-skin-sshot.gif!The Spark Skinning Service has been a hot topic here at Jive for the past couple of weeks. The service is not yet ready to serve up customized builds of Spark 2.5 (it will be ready late May) and it turns out that one small change to the service will make it much easier to keep the Skinning Service up to date with the latest Spark release. What's the change? Removing the ability to change the color of Spark. So in the interest of staying in sync with Spark releases, we'll be removing this functionality.

 

We have also decided to stop selling Spark Skinning as a stand-alone service. Instead, it will only be available as part of Openfire Enterprise Edition. Current customers of Spark Skinning will not be affected. If you have a subscription to the service already it will continue to work until the current subscription runs out, and there is an upgrade path to Openfire Enterprise to keep the functionality after that time.

 

Spark Skinning is being phased out as a stand-alone service for a couple of reasons. First and foremost, the changes to Openfire Enterprise pricing substantially lower the barrier for small deployments while maintaining value-based prices for larger deployments. The second reason is that the amount of administration required to keep two sets of Spark Skinning accounts functioning smoothly became too onerous. Simplifying to a single account type will help considerably.

 

As always, let me know if you have any thoughts about Spark Skinning or these changes.

Matt Tucker

Props to LG

Posted by Matt Tucker Champion Apr 9, 2007

!http://www.igniterealtime.org/blog/wp-content/uploads/2007/04/props.png!Earlier today, LG (IT2000) passed Gato to become the top point earner in the ignite community forums. It's the first time ever that an outside community member has jumped ahead of Jive Software engineers, which is a pretty impressive feat. With a current score of 3475 and 5 to 10 points per question answer, that's a lot of people he's helped out -- especially considering that not everyone remembers to award points.

 

So in the spirit of Ali G, all of us at Jive Software want to offer mad props to LG.

As many of you may have noticed. the IM Gateway plugin version 1.0 was released alongside Wildfire 3.2.3.  (sorry guys, I can't call it Openfire until the official release is 3.3.0 )  The release was quite a step for me as I've never actually released a 1.0 of anything!  Typically I'll take the attitude of having to get everything perfect before I can release a 1.0.  One of the things that Jive helped me realize is that I could label some of the problem children (Yahoo, ICQ) support as experimental and basically release a 1.0 with good solid support for the rest of the protocols.  That hadn't occured to me before and I'm quite glad to see 1.0 out.  Amazingly enough, there haven't been a lot of bug reports.  I hope that everyone who is using it is enjoying it.

 

I must admit that pushing Yahoo and ICQ support to the side "hurt" a little.  However the library I'm using for Yahoo isn't particularly stable and the ICQ support in joscar isn't entirely golden either, and I didn't want to see the release drawn out way into the future.  I am pleased to say that the Yahoo library is getting some love as we speak and there's been improvements to the ICQ support submitted to the joscar team and I'm working on a couple of other improvements.  I would consider myself highly familiar with the OSCAR (AIM and ICQ) protocol itself, but not at all for Yahoo.  (I'm referring to the low level details of how the protocol itself works, in theory the libraries I use ought to hide the details from me)  As it turns out, I'm getting more familiar with the MSN protocol as I ended up taking over as lead developer of Java-JML.  Thankfully, I've got some help on that front as well.  It's always nice to see help coming in from many angles!

 

So what's coming next?  Well, my highest priority is to get ICQ fixed up.  Once the Yahoo library improvements come about, I'll be aiming to solidify that as well.  Of overall new features, I'm waffling between groupchat and file transfer.  Groupchat is now the most voted for feature for the plugin.  File transfer, on the other hand, is something I've never had an opportunity to get involved in, so generally I'm interested in learning how it works by diving into it.  Buddy icons are also highly voted for.  Such a seemingly pointless/unimportant feature, but I'm with you all; it's one of the features that gives me the biggest joy to see in a chat client.  They're just so cute.  ;D

 

Why did I title this Looking Throught The Fiery Gate?  Well.. it's a gateway plugin.. it's in Openfire/Wildfire...  yeah. 

Filter Blog

By date: By tag: