Ignite Realtime is the community site for the users and developers of Jive Software's open source Real Time Communications projects. Your involvement is helping to change the open RTC landscape.
Most of our projects have a long history. This certainly goes for Spark, which was created over ten years ago. Although many of you are actively using Spark today, it is beginning to show its age. This is something that we have been planning to address for a while now.
Spark was created around the same time that the Kyoto protocol went into effect, Pluto got demoted to the status of 'dwarf planet' and Italy won the FIFA world cup in Germany. Thereabouts.
Since then, source code development tooling has improved a lot. Today, the Spark project is struggling to find active contributors. We believe that one of the reasons for this is that it's pretty hard for developers (especially those that are used to work with modern tooling) to get started with our project. We have been working on that. First, we moved all of our projects from our old Subversion repository to Github. We have noticed that this dramatically improved the accessibility of our code. Second, Smack 4 happened, bringing the backbone of Spark back up-to-date.
Now, we are addressing the structure of the project itself. We will restructure the project as a Apache Maven project. This will bring a good deal of predictable structure to the project, which has many benefits. One of these is that the project will integrate easily with various development tools.
Moving Spark from its existent Ant-based structure to a Maven structure is no small task. There is no one right way of doing this. We have given it a shot, and have created a structure that we think is very workable. Before committing to this structure, we would very much invite others to have a look, and comment on what we've done. The reasoning behind this is simple: once we've committed to a particular structure, it will be disruptive to change it. If we want to apply improvements, we should do so now.
Please, review our new project structure, and let us know what you think. You can find the new structure in the SPARK-1791_Maven branch on Github.
Ask yourselves: does this structure help me? Is it easier to compile the source code? Can I integrate it with my IDE of choice without too much trouble? Can I create new plugins? Does the new structure introduce a problem that needs to be addressed before committing? Can it be improved? We welcome all feedback!
I am trying to build a new web based client for Openfire to replace the outdated and abandoned Flash-based Sparkweb. The project is called Pade (A Yoruba word for Meeting) and my first step was to decide on my web client API.
Representational state transfer (REST) has now become the standard for abstracting request/response type web services into an API. When it is combined with Server Sent Events (otherwise known as Event Source), the result is a fresh new way of providing two-way real-time communication between web clients and a server using synchronous requests/responses (IQ) with REST and asynchronous evening (Message, Presence) with SSE. The really cool feature of SSE is the automatic re-connection by the web browser.
The Rest API plugin by Redor is brilliant . It allows you to administer Openfire via a RESTful API. Most of the common functions we do from the Openfire admin console web application can now be automated and integrated into server-side Java plugins or client-side web applications with ease. After spending hours inside the code and extending it for use at work to manage all the telephony entities we use with our Openlink XEP from the various commercial plugins we develop, it became clear that REST+SSE is the way forward for web-based real time messaging. Don't take my work for it. Read what the folks at erlang-solutions.com have to say.
As my first step towards implementing Pade, I have built a Chat API plugin by extending the REST API plugin with SSE and Jetty web authentication taken from the Openfire meetings plugin. The plugin now runs on the HTTP-BIND (7070/7443) port instead of the admin (9090/9091) port. It authenticates you as an Openfire user once and reuses the authentication for REST, SSE and XMPP bosh/websockets. It supports everything you can do with the REST API plus Bookmarks and SIP Accounts as an admin user. It then enables you as a normal user to handle presence, chat, groupchat, contacts and users with just a handful of REST requests and SSE events.
The Ignite Realtime Community is pleased to announce the availability of version 4.1.2 of Openfire. This release signifies our ongoing effort to produce a stable 4.1 series while effort is made on new features and functionality in Openfire 4.2. You can find a release changelog denoting the 13 Jira issues resolved in this release. If you had issues with inconsistent appearance of groups, do please test this release to see if those issues are now resolved. You can download the release from our website here and the sha1sum's for the available artifacts are as follows.
|OS||sha1sum||Filename||Version 4.1.1 Downloads |
|Linux RPM (32bit JRE bundled)||c2f12c3ec6ba2f64388279f106f2749272c9504c||openfire-4.1.2-1.i686.rpm||1290|
|Linux RPM (no JRE)||226a7f1138fda7c456523bf80e6140e020fd5a74||openfire-4.1.2-1.noarch.rpm||965|
|Linux RPM (64bit JRE bundled)||6892ec82e1435b6cbf23da1ba1efb9d94122d8a6||openfire-4.1.2-1.x86_64.rpm||3805|
|Mac OS dmg||b9570c78854c226714c23001997119e503e0aaab||openfire_4_1_2.dmg||1207|
 We recently migrated to storing our release artifacts on Github and thanks to their API, we can get metrics on how many times the artifact was downloaded.
As a reminder, our development of Openfire happens on Github and we have an active MUC development chat hosted at email@example.com . We are always looking for more folks interested in helping out, so please consider pitching in!
As always, please report any issues in the Community Forums and thanks for using Openfire!
I've just released Smack 4.2.0-rc3 to Maven Central. Smack 4.2.0 is scheduled to be released early Q2 2017, according to Smack's release life cycle. And right now, it looks like the train is right on time.
I am happy to announce that we are bringing back one of our older projects from the grave: the Asterisk-IM project! This project was started in 2005 by Jive Software, and can be used to integrate the Asterisk platform in Openfire. Due to a lack of manpower over the last few years, development stalled. No longer!
We have found the most excellent Marcelo Terres willing and able to take on the reigns as project lead for the project! Simultaneously a code contribution by Ron Arts brought back compatibility of the Asterisk-IM source code with both recent versions of Openfire, as well as Asterisk 13 - but more on that later, from Marcelo.
I am more than confident that the project is in good hands with Marcelo. Not only has Marcelo been a active manager of the primarily Brazilian-based Openfire community, he is heavily involved in the Asterisk project, going as far as to speaking on AstriCon 2016.
As of now, we restored references to the project in our Ignite Realtime community. There is some more work to be done: downloads still point to an older release, and we might be lacking a bit of project infrastructure (such as an issue tracker, dedicated community forum, etc), but I'll leave that to Marcelo to put in place as he sees fit.
Marcelo, thanks for doing this! I'm excited to have you on board (as far as you weren't already)!