After Gato made this suggestion in my last blog, I decided to move this request to the top of my to-do list as I also need it for another project I am currently working on.

How does it work?

I am using the Flex Dashboard developed by ESRIA which was donated to the Adobe Developer Connection. Plugins are presented in a pod layout called a View. Each View occupies a Tab in the SparkWeb ChatWindow. You can modify Views by dragging and dropping pods to a different location and minimizing, maximizing, and restoring pod windows. View changes are saved using a LocalSharedObject. View configuration data is loaded from sparkweb/plugins/plugins.xml with values in plugins.xml indicating which swf file to load for a particular pod within each View.

<views>

<view id="view0" label="Plugin Demo">
  <pod id="app01" title="User Moods" dataSource="plugins/moods.swf" />
  <pod id="app02" title="User Tunes" dataSource="plugins/usertunes.swf" />
  <pod id="app03" title="Demo" dataSource="plugins/demo.swf" />
</view>

</views>

SparkWeb will load each pod SWF file and call the method setParentApplication passing it the SparkWeb root Application object. From this object, you can navigate your way to access all other SparkWeb public objects and even add eventhandlers on events like NewMessage for example.

To get a feel of what can be done, I decided to implement the User Tunes and Moods PEP (personal eventing protocol) applications. See Armando Jagucki's blog for more details about PEP in Openfire. The source code to the demo plugins is in the src/plugins folder.

For those interested, the latest version of Red5 Plugin for Openfire can be found at _http://red5.4ng.net/red5-0.1.06.zip. Remove comments in plugins.xml to activate the demo.

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!

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

When SparkWeb became open-source, I took a look at the source code and found it had more features than the Flex-based XMPP client I was co-developing for the Red5 Plugin. It therefore made sense to migrate the Flash audio and video features we had developed for our client to SparkWeb and make it compatible with the Spark and Openfire Red5 Plugins and package it as part of the Red5 plugin. The downside to this that the modifications to the Red5 version of SparkWeb makes it out of sync with the official SVN and it could possibly become a fork requiring a name change later on.

So what does the Red5 SparkWeb offer?

1. A plugin container for SparkWeb. I noticed  that quite a number of users are asking for a plugin to deploy SparkWeb. My advice would be to try the Red5 Plugin.
   
   Configure  Index.html and point your users at
   
   http://your_server:nnnn/red5_webapp_name/sparkweb
   
   Where nnnn is your HTTP-BIND port number (default 7070) and red5_webapp_name is your default red5 web application name (default red5)
   
   
2. Enables use of the Red5 plugin audio and video features with both Spark and SparkWeb. You can't do video messaging and the video roster is replaced with visual presence (see below). You can make audio/video calls and share your desktop with your contacts. Each call record is logged in openfire and can be queried by the administrator with the Openfire SIP plugin.
   
   
3. Makes SIP phone calls between Spark and SparkWeb users. All SparkWeb SIP calls are logged with the Openfire SIP plugin as well.
   
   
4. Provides webcam support. If you have a webcam installed on your PC, it will be automatically detected and will be used instead of your vcard photo. You can disable this in index.html. You can add or replace your vcard photo with a snapshot of your webcam when you edit your profile. You can also publish snapshots from your webcam as visual presence to all your contacts. What this means is that all your contacts will have  a snapshot of your webcam in their rosters. The interval between snapshots is 60 secs by default and can be modified in index.html. See a draft copy of my proposal to extend XMPP with visual presence. Please feel free to post comments at the bottom of the document.
   
   

I also made a few cosmetic changes to my taste and added sound effects for incoming calls and instant messaging. I added some code to improve the loss of focus detection by tracking Flash application activation/deactivation messages and mouse movement. If you use Internet explorer and enable pop-ups, you will get a pop-up in the bottom right corner of the screen with a photo, name and first line of the incoming messaging if you are outside of SparkWeb when a new message arrives.

I am hoping to add fastpath support and a calendar to SparkWeb next.

Whack 1.0 has been released. Whack is our Open Source XMPP (Jabber) component library for XMPP components. External components are processes that run outside of the Openfire's process but can connect to the server to register new XMPP service. Whack is an implementation of XEP-0114: Jabber Component Protocol.

Unlike the other igniterealtime products, Whack followed a different evolution path. We started coding Whack around November 2004 and after a few months it was operational. Openfire and Whack share the same component's API so around 2005 we were able to run Fastpath as an internal component (i.e. running in the Openfire's process) or just move it as an external component using Whack. It was impressive seeing the same code running as internal and external. Since then Whack continued to evolve but always at a very slow pace. Whack was always stable in each step but it was just not ready for prime time. We wanted to keep adding more things to it to reach a 1.0 release. Since our collaboration software Clearspace uses Whack to integrate with Openfire we needed to push the boundaries of Whack once again and I'm happy to say that we now reached the 1.0 release. And that is why we decided to make a public release in 2008 after 4 years of continuous but slow growth.

A few months ago we also released a new product called SparkWeb. SparkWeb is our Open Source web-based IM client. SparkWeb is based on XIFF just like Spark is based on Smack. Today we updated the products page to list SparkWeb as an official product. Welcome SparkWeb! The family has grown a little bit now.

You can get Whack from here. Questions could be posted to the Whack forum.

SparkWeb can be downloaded from here. If you want to build from the source code you can read the Getting and Building SparkWeb document.

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.

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

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