Skip navigation
All Places > Ignite Realtime Blog > Authors Daniel Henninger

Ignite Realtime Blog

14 Posts authored by: Daniel Henninger Champion

We are very pleased to announce the release of Openfire 3.6.0!  It has been a long time coming and may well include the highest number of bug fixes and improvements we've ever had in a single release.  Don't quote me on that, but it's certainly the largest number I recall seeing.  =)  While the bulk of them are bug fixes, there are a couple of big improvements I would like to highlight!

 

Clearspace Integration Improvements

We've improved upon the integration between Openfire and Clearspace quite a bit.  Most are bug fixes and performance improvements, but also some new backend features that further solidify the bond if it is set up.  Openfire now includes a Clearspace tab when integration is enabled so help make sure the link is performing properly.  On top of that, there are a lot of features in place in preparation for the addition of real time chat support in Clearspace.  More information will come on that at a later date.  We've also renamed the tables Openfire uses to make it easier to install it alongside other products in the same database, if you so choose.  The automatic upgrade procedures will take care of all of the hard work for you, so you shouldn't need to give it a second though.

 

LDAP Support Improvements

Openfire's LDAP support had some holes in it here and there that should be filled now.  Altbasedn, for example, was not used everywhere.  There is now support for alias following (or rather, turning it off), paged results (to make sure to get all of the available results instead of a subset), and a number of bug fixes for existing functionality.  Internally, a lot of the code has been cleaned up.  I still have a couple of things up my sleeve here and there for a future release, but I'm quite pleased with how this is looking now.

 

Multiple Conference Services

Every wished you could have more than one conference service set up with different rules?  Maybe you wanted one for public access with no room creation rules and restrictions, but also wanted an internal "protected" service that abided by strict rules.  Maybe you just wanted to set up some sort of specialized set.  Maybe you never wanted -any- conference services and just wanted to delete them.  Whatever the reason you might have, you can now set up as many or as little as you want.  In some cases, plugins may even be able to take advantage of a specialized service setup.

 

BOSH (HTTP Binding) Improvements

With many thanks to our Google Summer of Code student, Safa Sofuoglu, we now have updated BOSH 1.6 support, and a ton of misc bug fixes and improvements.  Improvements in this area were also performed on the connection managers!  I encourage you all to read about it in his report:

GSoC 2008 Report: Openfire and SparkWeb

 

More Configuration in Database

The openfire.xml config file was getting bloated and a lot of the configuration in it could easily have been moved into the database.  As a result, we've moved just about everything that doesn't fall into a category of:

  • how to connect to the database itself
  • config info specific to host itself

 

Why you might ask?  In a clustered environment, it makes it so you can set Openfire up once and now have to reconfigure the providers and such for each cluster member individually.  It also paves the way for support for things like, admins stored in the database, which means you can update the admin list on the fly, instead of having to edit openfire.xml and then restart the server.

 

Plugin Updates

It's important to update the following plugins to account for changes in the 3.6.0 API:

  • User Search
  • IM Gateway
  • Fastpath
  • Monitoring

 

Where Do I Get It?

 

You can download Openfire 3.6.0 here.

You can see the entire changelog here.

You can view the documentation for 3.6.0 here.

Plugins can be downloaded from the admin console or here.

As you most likely already know, we upgraded Ignite Realtime to use the latest Clearspace pending release, version 2.5!  We also upgraded a few things on the rest of the site, but they were primarily backend things.  I'm very excited to finally get Ignite Realtime up to a recent version!  I've been using this for a while internally and also on one of my own sites, and have been eagerly awaiting it's arrival at Ignite!  So with the new site, I wanted to go over some of the new features of Clearspace 2.5, and also a few plans we have coming up!  First of all, 2.5 has a number of cool new features that I wanted to go over, those are as follows:

 

Social Groups

Ever wished you could set up arbitrarily groups of community members who share a similar interest?  Maybe you wanted to coordinate on a project or just have a little space to chat about something you all find interesting?  With the new Social Groups feature, you can create whatever groups you want, complete with their own discussion spaces, documents, etc!  You can browse all of the available groups under Browse -> Groups in your user toolbar, join ones you find interesting, create new ones from the New menu.  It's completely up to you what you might want to put together!  It's all separate from the primary spaces so you won't interfere with anything going on in the primary site.  I'm highly interested to see what you all come up with!  Want to create a group that no one knows about but you and other members?  You can also set up private groups!

 

 

Custom Views

Don't like the layout we've chosen for the main page?  Tired of our layout dictatorship?    Well with this version you can set up your very own "Your View".  You'll see a tab for this when you go to the main Community page, and from there can customize to your heart's content!  Completely messed up your view?  Please post in the forums so we can laugh at you!  Kidding.    Seriously, there's a "Default" button you can press to return yourself to the original setup.  Plus at any time you can view the regular view by simply selecting the All Content tab.

 

 

Rich Text Editor

The new version boasts a rich text editor that actually works great!  We received a number of complaints about the previous rich text editor and it's numerous issues and made sure to provide something that folk can actually use!  Part of the problem with the previous editor was trying to support both rich text and wiki markup and plain text and... you get the picture.. you end up having to cobble together things that aren't meant to work that way.  The rich text editor wanted to do regular HTML in the background, but that conflicted with wiki macro.  Now, I know a few of you have brought up wanting some of the wiki macros back, and I have relayed this back to the developers of the editor, so stay tuned!  I will say this though, I thought I would never like a rich text editor, I always felt they messed something up for me, and this one is the first one I've actually enjoyed using.  There's a couple of kinks we are still working out though, so please bear with us!

 

 

 

Regular Updates

Since we are now running the latest code, we can start performing regular updates again!  That means faster fixes for issues you all report and hopefully a lot of cool improvements along the way!  We are effectively running a beta right now, so updates will be fairly often for now.  Your reports will be invaluable in helping make sure this community runs super smooth!  And since we're not running a release right now, bugs should get fixed quite soon after being reported! 

 

 

 

So That's Great, What's Coming Up

One of the things we've been working on heavily lately has been integrating real time chat wih Clearspace.  In the near future, we will be adding the chat plugin to Ignite Realtime, which will provide a number of cool things such as real time chat in spaces and social groups, automatic chat transcript recording, and scheduled chat events (similar to our weekly developer chat that you are probably familiar with).  In fact, we may be migrating the weekly chat to a room provided by the plugin!  Does this mean you can't connect from an external server?  Of course not!  The JID might just be different.  =)  Gato been making a lot of posts about the new functionality in the Jivespace community, you can read more about them in the following posts:

 

 

 

I Found A Bug, What Do I Do?

Your help in reporting bugs you find in the new site is invaluable!  I am monitoring site bug reports regularly and am passing any feedback back to the Clearspace developers.  Please report any bugs, concerns, or thoughts in the Jive Lounge, or even as a comment here if you'd like.  I want to thank all of you for your assistance in helping not only Ignite Realtime be the best it can be, but Clearspace as well!  Don't be afraid to nitpick.  We'd love to hear anything at all that you have to say!  I can't guarantee that every single issue will be taken care of, but we'll sure consider anything we hear!  Also if you don't feel comfortable with posting publically, you are welcome to private message me directly.  Thanks everyone!

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

 

 

If you install the Monitoring and/or Fastpath plugin, make absolute sure that you read the readme first!  There are included instructions for how to migrate your database from the Enterprise plugin to the new plugin database tables.  If you have ever run the Enterprise plugin or the old Fastpath plugin before it was integrated with Enterprise, make sure you don't forget this or you will be unhappy!

 

 

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.

As you may have already seen, Openfire 3.5.0 was released today alongside it's good friend Clearspace 2.0!  We are excited to put out this release as it strolls alongside a number of new announcements, new features, and is sporting a brand new outfit in the form of a new look and feel for the admin interface.

 

Now, in light of the announcements regarding the Enterprise plugin becoming open source, you may be wondering why you can see an updated Enterprise plugin available.  We are providing this plugin for our existing enterprise customers until the separate split-up plugins are released.  Those of you waiting for the open source releases, please stay tuned!

 

For our Clearspace customers, this new version of Openfire integrates at a much more intense level than before.  Instead of simply providing presence to Clearspace, and requiring you to point both Clearspace and Openfire at something like LDAP to have the same login setup, you can now have Openfire speak directly to Clearspace.  It will pull it's users and groups, as well as pass authentication through Clearspace.  Setup is a breeze, as you have one screen of setup in Clearspace and one screen of setup in Openfire and you are done.  And we're not stopping there.  Future releases will include even more integrations between the two!

 

Is Clearspace integration the only new thing in Openfire 3.5.0?  Of course not!  We've now got the ability to disable accounts, security audit logs for admin events, easy to take advantage of invisibility, and did I mention the pretty new admin interface?  We went over a lot of these new features in a previous blog post, so I won't bore you with a complete rehash of all of them. 

 

One word of warning, due to the nature of CSS not wanting to easily refresh itself, you may need to shift-reload in your browser for the new admin console to look correct.  And don't forget to update your plugins after upgrading to 3.5.0!  Some of them are affected by API changes!  (specifically: User Search, IM Gateway, MOTD, and SIP)

 

This has been a very exciting day for us here at Jive and we hope exciting for you as well!

 

You can download Openfire 3.5.0 here.

You can see the entire changelog here.

You can view the documentation for 3.5.0 here.

Plugins can be downloaded from the admin console or here.

As it turns out, not long after hitting the 1,000,000 download mark on Openfire, we hit the 3,000,000 mark on the sum total of the Ignite Realtime products!

 

 

Many thanks to the community for your interest, involvement, and support!  Matt says it best in his post on Jive Talks, so I shall leave it at that.  =)  Guess it's time for more toasts to the Ignite Realtime community!  Thanks everyone!

We are pleased to announce the availability of Openfire 3.5.0 RC1 off of the beta downloads page, along with Openfire Enterprise 3.5.0 RC1 off of the beta plugins page.  The official release is slated for late March or early April, depending on when the official release date of Clearspace 2.0 is.  There are a number of new features and bug fixes in this release.  A couple of the highlights are as follows:

 

New Security Features

 

3.5.0 includes two new improvements to the overall security of Openfire.  One is a new lock out manager, which allows administrators to lock out (disable) accounts, thereby preventing them from logging in.  This can be for a period of time, or "forever".  Another new security feature is a new auditor for actions performed in the admin console.  This will allow you to keep track of what has changed in your server's configuration, and who performed the change.

 

For more information, see: Big Brother In 3.5.0

 

Invisibility

 

3.5.0 includes the ability to connect without sending an available presence.  This provides an easy means for being "invisible" to other XMPP users, and visible specifically to those you intend on speaking to.  This support needs to be built into clients or programs that you might be using to be of direct use, but the capabilities are now available!

 

For more information, see: Playing Casper in 3.5.0

 

Clearspace Integration Improvements

 

Clearspace 2.0 and Openfire 3.5.0 can now work together harmoniously to share users, groups, vcards, presence, and various other functionality.  Not only that, but Clearspace and Openfire will configure their integration in a semi-automatic mode, where you provide a minimal configuration of Openfire and Clearspace and they take care of the rest!  You will see a new option during initial setup where you can choose Clearspace integration that will lead you through the steps.  Please note that Clearspace 2.0 or higher is required for this integration to function properly!

 

For more information, see: Clearspace 2.0 Public Beta

 

Performance Improvements

 

A number of improvements have been made to the overall performance of Openfire in 3.5.0.  An important index was added to one of the database tables that improves roster loading speed by a large degree. The networking framework used for external component connections has also been replaced with MINA, drastically improving the performance of external component connections.

 

Fixed Double-Byte Character Problems

 

3.5.0 includes fixes for double-byte characters not being handled correctly.  This should solve a number of problems with messages that include chinese characters, or other double-byte character encodings.

 

SparkWeb Enhancements

 

SparkWeb 3.5.0 includes a number of reliability improvements, especially with http binding, and also improved support for MUC functionality, such as moderation controls (kick/ban/etc).

 

New Admin Console Look and Feel

 

3.5.0 sports a brand new look and feel for it's administrative console.  Those who have used Clearspace before will be familiar with it, as it's mirrored in concept and general look after Clearspace's administrative console.  The new menu layout is much less cluttered than before, and should involve a lot less scrolling down the page to find what you want.  Warning: Due to changes in the CSS files, and browsers wanting to hold onto CSS files for dear life in their caches, you will likely need to hit shift-reload on your browser when visiting the new admin console.

 

And more!

 

You can view the full changelog here.

You can view the updated documentation (javadocs et al) here.

Plugin updates required for Openfire 3.5.0 are available on the betaplugins page.

The specific plugins that need to be updated are:

  • IM Gateway

  • User Search

  • Enterprise

  • MOTD

  • SIP

 

Happy testing and please let us know of any issues you run into by posting in the  Openfire support forum!

 

Thanks!

-The Openfire Team

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!

We are very pleased to announce that Openfire has breeched one million downloads (not including downloads not from our site)!

 

 

We couldn't have done it without you all, the Ignite Realtime community!  (well of course not, we needed -someone- to download it    )  It's always fun to watch a milestone come and go, and take a moment to reflect, so I thought I would take a little bit to talk about Openfire's history, and even a little about my own personal history with it.

 

When I first found what is now called Openfire, it was somewhere in early 2006.  At the time it was called Jive Messenger and I was the lead developer of PyAIMt and PyICQt and was told that my transports didn't work well with Jive Messenger.  It wasn't long before I 'fell in love with' Jive Messenger and around the middle of 2006, I began work on the IM Gateway plugin.

 

Not long after, I watched Jive Messenger turn into Wildfire, run into a naming conflict, and then turn into Openfire.  As it turned out, Openfire became probably the most appropriate name, as it better reflected the open nature of the product, and was really catchy!

 

So approximately two years after I first became aware of Openfire, we've hit one million downloads!  That's pretty impressive for a server product!  Over those two years we've witnessed so many milestones in the world of XMPP.  One might even call it a "boom time" for XMPP at this point.  So lets all have a drink to Openfire's one millionth download, and to XMPP everywhere!  And also, we at Jive will be having a virtual toast to the Ignite Realtime community, and thank you for all of your involvement!  Happy road to two million!

Daniel Henninger

Big Brother In 3.5.0

Posted by Daniel Henninger Champion Feb 27, 2008

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?

Monday, after a long period of heavy development, I finally put out version 1.1.0 of the IM Gateway plugin! A total of 85 issues from JIRA were closed along the way and I'm quite pleased with the results. Along the way there were a number of stumbling blocks where I would just about be ready to release and something major would come up, and I certainly did not want to release anything with serious issues going on. As development continued, more and more features became interesting to me and were implemented. Since 1.0's release, I've had a number of helpful folk step up and offer patches, testing, code, translations, and help with libraries I depend on. I want to take a moment to thank everyone who contributed in any way! You are all invaluable to me!  There are a number of big plans coming for the next major release, but I wanted to highlight some of the things from 1.1.0's release and even comment on some of it!

 

First off, there's XMPP/Google Talk support. One might ask, why do you want XMPP support when there's s2s? That's a question that's been fought many times in the past and typically results in nothing being decided. Well I decided to implement it and then another helpful person (thanks Mehmet!) took my piddly start with it and turned it into a full on transport for the plugin. After implementing it I found myself using it with some accounts I had seen no reason to add to my Adium X config but decided hey, if I can handle it server side, then I'll just carry it around with me. Has been working out really well!

 

Then there's Gadu-Gadu support. This is a protocol I did not expect to ever implement. Why? Everything about it is Polish. I couldn't find my way around the web site enough to even download a copy of the client.  However, I said early on that if someone would translate or help me download or generally help me get it set up and there was a good API out there, I'd do it. So thanks to Marcin for stepping up and helping me get this started! The API itself was amazingly enough the easiest API to work with yet!

 

And what about SIMPLE support? Thanks to Ravin and Patrick for writing this support as I wouldn't have even known where to begin! I still don't understnad SIP/SIMPLE. Who knows if I ever will. But the transport sure works with my OpenSER server! I'm hoping some folk will take a look at it so I can get a feel for what it does and does not work with and maybe I can work with them to tweak it to work correctly with various implementations.

 

Another interesting thing that was added is an XMLRPC interface so site administrators can write their own web front ends for users to register with the various transports. That way folk could use some various standard web look and feel for the registration, and/or their own authentication mechanism, or even just something they consider "nicer" for their users, and dodge around typical requirements of registering through a client or requiring the admin to do it for them.

 

A lot of the inner workings of the plugin were redone, making things a lot more efficient in terms of network traffic and overall coding structure. I don't know that anyone but me will appreciate the reworkings of the code, but hey. =)

 

One of the interesting things that came about is that I ended up as the lead developer for Martyr, a very cool IRC library. IRClib just wasn't getting it done for me so I tried out Martyr, adored it's structure, and offered to help improve it. It's already led to a far better IRC transport than what I had before.

 

Beyond that I want to thank the folk from nimbuzz for creating the wonderful project OpenYMSG (a fork of YMSG) that fixes a number of problems I kept running into in the past! Through their improvements Yahoo support in the IM Gateway plugin was promoted to being considered stable!  On top of that they've helped me out some with JML, the library that handles MSN support. Great work folk!

 

Well that's enough of me, I'm excited about things to come though and I hope you all will join me in that excitement and continue to help me with testing, ideas, and whatever! =)

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. 

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: