Blog Posts From Ignite Realtime Blog Tagged With xmpp

Openfire 3.7.1 has been released!

communityadmin@igniterealtime.org — Sun, 02 Oct 2011 19:35:24 GMT

The Ignite Realtime community is happy to announce the release of version 3.7.1 of Openfire! Downloads for various platforms are available here.

Openfire is a real time collaboration (RTC) server licensed under the Open Source Apache license. It uses the only widely adopted open protocol for instant messaging, XMPP (also called Jabber). Openfire is incredibly easy to setup and administer, but offers rock-solid security and performance.

The 3.7.1 release is primarily a bugfix release. Amongst others, these issues have been addressed:

A number of enhancements were made to the server-to-server connectivity. Server-to-Server connectivity was enhanced and a bug preventing a successful dialback was fixed.
Various improvements have been made to platform specific installers and scripts.
The Multi-User Chat implementation has received various tweaks and updates.

The full changelog is available on the Openfire project page.

We welcome your feedback, suggestions, tips, hints, questions and other contributions in the Ignite Realtime Community pages.

Openfire 3.7.0 beta has been released!

communityadmin@igniterealtime.org — Thu, 26 Aug 2010 21:05:39 GMT

Good things come to those who wait!

The Ignite Realtime Community is pleased to announce the beta for the next release of Openfire. This release contains a number of important fixes and improvements to stability and XMPP protocol compliance. You can find a full list of fixed issues here. This beta is also the first version of Openfire to be released by the Ignite Realtime community under the Apache License v2.0.

You can download the 3.7.0 beta release here. Please provide us your feedback on the Ignite Realtime support forums. It would be helpful if you would tag your comments, discussions and questions with a tag that reads "openfire370beta"

As always, but particularly since this is a beta release, make sure to backup any existing version of Openfire and the persistent storage that it uses, before upgrading!

Some important security related notes to this release:

Openfire no longer ignores the system property to disallow password changes via XMPP. With previous releases, it was not possible to prevent users from changing their password via their XMPP connection. (CVE-2009-1596)
Fixed a XSS attack on the admin console login form.

Protocol compliance improvements:

Publish Subscribe (PubSub)
BOSH (http-bind) xml namespace compliance fix.

Some highlights of this beta release:

Improves how Openfire handles "idle" connections. Some of you may have the system property xmpp.client.idle set to -1 to work around previously broken behaviour. You may now let it default to 6 minutes or set it to your preference.
Improved Openfire's caching to be less prone to memory exhaustion by correctly calculating cache size usage.
Fixed a bug where admin console login into a newly installed Openfire server would fail until restarted.
Fixed a bug with shared rosters within a LDAP environment.
Openfire now ships with the latest JRE (1.6.0u21).
A memory leak with the Personal Eventing Protocol (PEP) was fixed.
Openfire's custom log interface has been replaced with SLF4J and a Log4J backend.
Fix issues with self signed SSL certificates.
A number of improvements and fixes were made to the Multi-User Chat (MUC) configuration pages on the admin console
There were also some improvements made to the plugins.
There are also French, Russian, and Lithuanian langauge translation fixes for Openfire and some of the plugins.

Red5 + Openfire = redfire

communityadmin@igniterealtime.org — Tue, 27 Jul 2010 16:11:39 GMT

redfire is the future of the Red5 plugin for Openfire.

In an attempt to maintain a single version of Red5phone and keep Openfire (ver 3.7.0) in step with Red5 (ver 0.9.1), I have chosen to embed Openfire inside Red5 instead of the other way round.

I have posted the first version at http://code.google.com/p/redfire/

This first version is just only Openfire 3.7.0 beta running as a web application in Red5. You acess Openfire web console the same way. http://your_server:9090

I will be adding the improved redfire sparkweb client with latest versions of red5phone, red5screen-share and support for onesocialweb later on.

Introducing Tinder, an XMPP object implementation library

communityadmin@igniterealtime.org — Mon, 22 Jun 2009 23:42:32 GMT

We've just released a new project, named Tinder. Tinder is a new Java based XMPP library, providing an implementation for XMPP stanzas and components.

Tinders origins lie in code that's shared between Jive Software's Openfire and Whack implementations. The implementation that's provided in Tinder hasn't been written again from scratch. Instead, code has been moved from the original projects into Tinder, preserving al of the existing features and functionality. Most of the code that's now in Tinder is based on the org.xmpp package implementation that previously existed in Openfire and Whack. This is the code that defines classes such as Packet, JID, IQ, Component and their extensions. Additionally, some multi-purpose code (such as the DataForm and Result Set Management implementations have been moved to Tinder as well.

Why a new project?

Parts of the code of Openfire are useful in other contexts than that of an XMPP server implementation. Developers might, for instance, want to use the XMPP stanza implementation within other projects. Having to include Openfire as a dependency of such a project is quite a bit of overkill. In such an example, it would be useful to have a small project that you can include, that offers you a lightweight XMPP object implementation, without the rest of the features that Openfire offers. Enter Tinder. Tinder will allow developers to re-use parts of Openfire, without having to include Openfire itself.

There's other benefits to Tinder though:

Tinder will replace some most of the duplicate code that's currently shared in Openfire, Whack and ConnectionManager projects. Removing duplicate code will make it easier to maintain and develop these projects. By delegating the implementation and maintenance of the low-level XMPP implementation, Openfire, Whack and other developers will be able to focus on the development that adds value to their project.

On the flip-side of that medal, you can argue that the 'core' code that will make up Tinder deserves a bit of dedicated development attention (unit tests, bug-tracking, stuff like that). This would benefit any attempt to really fine-tune the code, for example for high-performance tuning. Currently, the code is a bit put in the shadows of the other projects (of which they are part of).

So, will this replace Smack (the library that provides the base of Spark)?

No, definitely not. Smack offers a full-fledged XMPP client implementation, while Tinder only defines some XMPP building blocks. Tinder provides some basic objects on which a client library such as Smack could be build. However, Smack does not share the same code base as Openfire and Whack do. It's therefor unlikely that Tinder and Smack will be merged in the foreseeable future - there's simply to much difference.

What's next?

We've wrapped up a initial roadmap, in which we capture the first steps of the development of Tinder. As always, you're invited to contribute. We're looking forward to hear your suggestions, thoughts and ideas. If you're interested, you can find more information on the new Tinder-related community space and project page that have been opened on IgniteRealtime.org.

Adobe to Open Flash Platform Messaging Protocol

communityadmin@igniterealtime.org — Thu, 22 Jan 2009 21:04:10 GMT

SAN JOSE, Calif. — Jan. 20, 2009 — Adobe Systems Incorporated (Nasdaq:ADBE) today announced plans to publish the Real-Time Messaging Protocol (RTMP) specification, more..

This is good news for the Red5 project and the Red5 plugin for Openfire with the Red5phone Flash phone. It will be interesting to see if the XMPP Standards council will give the Jingle RTMP Transport proposal another consideration.

GSoC Project Successfully Completed!

communityadmin@igniterealtime.org — Thu, 21 Aug 2008 02:05:32 GMT

I am proud to announce that I have successfully completed my Google Summer of Code Project. As we hit the official pencils down date, I thought it might be good to publish results and final toughts.

I started the project in time and completed it 3 working days later than planned, though it could require more effort if we didn't change our goals. I cooperated with Tomas and Tobias to fix the flaws I couldn't notice during development. Changes I made to Openfire and XIFF are listed here and here. All changes have been imported into trunk and hopefully be included in next releases.

It was a wonderful experience to work on Openfire and SparkWeb, especially with my mentor Gaston. Even if my GSoC project is complete, I feel there'll always be something to do for me with Jabber. I am having fun with Jabber, and planning to continue working on Jabber development as a community contributor.

I would like to thank Google for giving me such a great opportunity. I also thank David Smith and Peter Saint-Andre for their excellent support.

See you around!

Roadmap updates for SparkWeb.

communityadmin@igniterealtime.org — Mon, 18 Aug 2008 01:43:05 GMT

This weekend I jumped back into development of SparkWeb to reacquaint myself with the list of outstanding issues/bugs in order to set a course for fixes and improvements. As a result, I have updated SparkWeb's roadmap in its issue tracker, adding a handful of bugs to be smashed in the weeks ahead for the 1.0 release (and also closed a lot of outdated ones). Clearly the next release will be focused on bugfixes and stabilizations. However, let's look into the void a bit further and see what new features and enhancements are on the horizon.

Dynamic Theming and Skinning

After developing on and using SparkWeb for nearly a year now, I have grown tired of its current skin and icon theme. In the code we are actually hardcoding a lot of color values and of course hardcoding the skin images themselves. This is not ideal in the least. Let's work towards a skinnable SparkWeb with updated icons. What I have in mind is something less "heavy" on the eyes, something like Yahoo's Flex skin they released under the BSD license:

As for the icons, they should also be themable. Imagine SparkWeb with a beatifully clean flex skin matched with the IM-related icons from KDE's Oxygen icon theme. I would like to see that, myself.

TLS Support

Secure communications over XMPP. Enough said, right? I am sure a lot of you would like this feature.

Plugin Framework

Easy extendabilitiy with the option to disable/enable certain functions would be great. I am sure a lot of you saw Dele's manipulations of SparkWeb adding Audio/Video communications. That is an obvious use case of such a framework, and I image his code would serve as a good guide for determining "plug points" in the code to implement it.

Stay tuned, and don't be shy to report bugs and submit patches of course.

--Armando

New Project Lead for SparkWeb & XIFF

communityadmin@igniterealtime.org — Wed, 13 Aug 2008 20:06:28 GMT

Hey all.

I have been selected as the new project lead for both the SparkWeb and XIFF projects here at the Ignite Realtime community. For about half a year David and I were the only developers contributing code to those projects on a full-time basis -- before SparkWeb's source was even opened up. I added initial support for shared groups, group chat invitations, kick/ban/nick-change announcements in group chat, various bug fixes, and a bunch of other little features here and there. With my previous work on SparkWeb I have seen first hand how its code has matured over the year. I think it is in a 'good' state right now, but clearly there is always room for improvements.

David has made a lot of necessary refactorings in the past that have improved its performance and Safa is currently ensuring SparkWeb is fully compatable with BOSH 1.6. Also, we have various other patches containing excellent improvements from other people in the community that will be included in an upcoming release. These two projects now have a decent amount of activity from outside of Jive, which is great.

From some recent conversations in the weekly chats it is clear to us that people feel comfortable with Openfire, the server -- and that what they are expecting to see is a client evolve to the same degree. I would like to hear more about this perspective so I can focus to make it happen in SparkWeb's use-case.

Interested in getting involved yourself? Well, what are you waiting for? This is an open source community after all... grab the source and join the fun. Send any of your code contributions, ideas, or feedback to me and let's make the most excellent XMPP web app/lib out there!

--Armando

GSoC 2008 Report: Openfire and SparkWeb

communityadmin@igniterealtime.org — Sun, 20 Jul 2008 20:44:31 GMT

I am working on BOSH support of Openfire and SparkWeb as part of the Google Summer of Code 2008. As we got past the midterm evaluations, my mentor Gaston and I thought it would be good to inform the community about what I have done so far.

My proposal involved updating and improving Openfire's BOSH support by updating the implementation to BOSH 1.6, and migrating Apache MINA as its connection provider.

I started with creating a load test environment to see Openfire's current performance, and created a document explaining how to use it. Then I ran some load tests using that environment. Unfortunately, the test machines I used were not enough to produce desired results.

As the next part of the project, I updated Openfire's BOSH to support both 1.5 and 1.6. Here is a summary of the update:

Added 'hold' and 'ver' attributes to the session creation response.
Fixed version checking. Before it was done using a double variable, which may show that 1.5 is newer than 1.10.
Script syntax support has already been added before. Finetuned it to prevent caching of responses.
Implemented in-order message forwarding (JM-1412), because further work seemed to be depend on this implementation. This is the part that took most of my time, also which made me to get more familiar with the code after long debugging sessions.
Implemented acknowledgements, which was intoduced in version 1.6.
Added support for session pauses, which was also new for 1.6.
Implemented overactivity checking. In 1.5, there was only 'polling too-frequently error', and a little description about it. Version 1.6 introduced a new section for overactivity, and has a detailed description of which circumstances should be considered overactivity.

With this update, I have seen that some BOSH issues I was not aware of (JM-1245, JM-1246) have also been resolved. The update has been merged into Openfire trunk, so you can grab and test it.

After the update, I started to investigate how to migrate to Apache MINA, and found out that it would be harder than we expected, because the version used by Openfire, 1.x, did not have any http support. We had also other alternatives, like Grizzly, so we deferred the decision about connection providers until we do some tests on them.

I am currently working on SparkWeb to make it fully compatible with BOSH 1.6. In the meantime, I am cooperating with Tomas Karasek, who is developing BOSH for Gajim, to resolve any BOSH related issues in Openfire.

I am open to any ideas/suggestions.

SparkWeb Open Source

communityadmin@igniterealtime.org — Wed, 23 Apr 2008 00:37:59 GMT

Earlier today I exported our svn repository for SparkWeb and committed the intial import to the new open source repository! Instructions for getting and building the source are available. Getting and Building SparkWeb. A chat room for discussion of SparkWeb development can be found at sparkweb@conference.igniterealtime.org. I'm looking forward to seeing what the community can do!

XIFF 3 Beta

communityadmin@igniterealtime.org — Wed, 02 Apr 2008 22:40:58 GMT

I'm happy to announce that we've just released an initial beta of XIFF 3.0, our open source ActionScript library for building XMPP clients. Continuing along the path set by Sean and the previous developers of XIFF, we've moved to embrace ActionScript 3 and Flex, while adding significant functionality improvements at the same time. Highlights include BOSH support, VCard support, and redesigned APIs. Feedback is strongly requested; It has been quite a while since a XIFF release, and a lot of things have changed, so I will be interested to see how the community feels about the direction we've taken things.

Some parts of this new release are still in a transitional stage. For example, SASL support is only available for BOSH connections at the moment. As more code is generalized between the BOSH and Socket connections, this limitation will go away.

XMPP Could Really Take Over the World

communityadmin@igniterealtime.org — Thu, 24 Jan 2008 23:47:40 GMT

David recently blogged about how XMPP is Taking Over the World starting with the recent AOL tests and his hopes that Microsoft, Yahoo, and QQ would follow AOL's lead.

Well, this must have got Matt thinking about how XMPP really could take over the world. His vision of XMPP is moving way past IM with a grand vision for how XMPP could be the future of cloud services.

I'll let you read his entire post over on Jive Talks, but here is a little snippet:

There's a new firestorm brewing in web services architectures. Cloud services are being talked up as a fundamental shift in web architecture that promises to move us from interconnected silos to a collaborative network of services whose sum is greater than its parts. The problem is that the protocols powering current cloud services; SOAP and a few other assorted HTTP-based protocols are all one way information exchanges. Therefore cloud services aren't real-time, won't scale, and often can't clear the firewall. So, it's time we blow up those barriers and come to Jesus about the protocol that will fuel the SaaS models of tomorrow--that solution is XMPP (also called Jabber).

Matt's post is also on Digg.

XMPP Is Taking Over The World

communityadmin@igniterealtime.org — Fri, 18 Jan 2008 00:53:30 GMT

Yesterday I ran across an extremely exciting fact: AOL is now running an XMPP server at xmpp.oscar.aol.com that accepts logins from AIM/ICQ accounts and can talk with AIM/ICQ contacts. This means that there's suddenly 53,000,000 more people (according to 2006 numbers from Neilsen/Netratings) that are accessible from XMPP. I've made a brief timeline of important events in XMPP's growth.

1999: Creation of XMPP

2003: Jive Software releases the first version of Jive Messenger

2003: XMPP passes ICQ in number of users

2004: IETF approves XMPP as an official standard

2004: Google Talk released, dramatically increasing XMPP's market reach

2005: Apple announces XMPP support in iChat and Mac OS X server

2006: LiveJournal adds XMPP support, creating 14 million XMPP accounts in the process

2008: AOL creates an XMPP-OSCAR bridging server, adding another 50 million or so users accessible via XMPP

As you can see, over the last four years XMPP has gone from a relatively tiny force to a huge player in the IM world. Now all we need is for Microsoft, Yahoo, and QQ to follow suit and most IM users will be able to talk to each other without the hassle of creating accounts on each service and using lots of different programs (or multi-protocol programs) to connect to them.

I'm extremely excited about the possibilities of this, although a little worried about the lack of public acknowledgement from AOL. Hopefully they will continue to move forward with this, and make an announcement in the near future.

Openfire Unleashed

communityadmin@igniterealtime.org — Thu, 01 Nov 2007 00:06:32 GMT

Openfire is the award-winning instant messaging server known for its simplicity, elegance, performance and extensibility. With each new major release, scalability has been improved; however, being able to scale a lot without redundancy or high availability poses a risk to every connected user if the single server goes down.

After many months of work that risk is now part of the history. Openfire Enterprise 3.4.0 provides support for clustering. Clustering will let you run Openfire on several machines serving the same XMPP domain. Clustering can be enabled with just one click from the admin console. Machines running Openfire Enterprise will automatically meet between them to form a cluster. With clustering you not only get high availability but also improved scalability. In our internal load tests, we got more than half a million concurrent connections sending lots of packets in a cluster of just 2 nodes.

Another nice addition to Openfire Enterprise is SparkWeb. Users can now connect to the server and chat from your website. Read the SparkWeb: Next Generation blog post for more information.

On the open source side we also have excellent news. More than 30 new features and more than 30 bugs were fixed. Personal Eventing via Pubsub was added so you can now publish your geo-location, music you are listening to and let subscribers be alerted. From the admin console you can manage users roster. Moreover, it is now possible to retrieve photos from LDAP and use them as users avatars. The complete set of changes can be found here.

You can download Openfire from here. Openfire Enterprise can be downloaded from here.

Enjoy,

Openfire Team

SparkWeb: Next Generation

communityadmin@igniterealtime.org — Wed, 31 Oct 2007 23:36:26 GMT

One of the new things other than clustering in Openfire Enterprise 3.4 is a new release of SparkWeb. This marks a number of major transitions for it:

Simplified Installation

First, it's now built into Openfire Enterprise. No more downloading a separate plugin, and no configuration required. You'll find it in a new sidebar item in the "enterprise" tab of the admin console.

Moving to Flash

!http://dscoder.com/sparkwebflex.png|style=float:right; margin-top:10px; margin-left:5px;|src=http://dscoder.com/sparkwebflex.png!

Second is that it's entirely new code. As we worked on the original SparkWeb, we ran into many limitations of the "ajax" (html + CSS + javascript + xmlhttprequest) platform, including browser compatibility issues, difficulty with localization, and the inability to support any sort of richer collaboration experience like voice or video. As a result, Derek DeMoro wrote a prototype of a web based XMPP client in Flash, using XIFF and Adobe's new Flex API. The new SparkWeb is descended from that, rather than from the previous version.

Work In Progress

There's good and (temporary) bad with this transition. The new code supports vcards and avatars, and is significantly smaller, resulting in quicker page loading. There's also a revamped UI, including contact list filtering much like Spark has. On the other hand, group chat support and secure connections are not quite ready in the new code, and are planned for the next minor Openfire Enterprise release.

If you have any questions or problems, feel free to post them in the ~~Openfire Enterprise Support forum~~