powered by Jive Software

Smack Development Meeting

The two Smack core developers, Matt Tucker and Gaston Dombiak, met in San Francisco during Java One to discuss the progress and future direction of the project. After congratulating each other on the growing success of Smack over the past year and deciding against ordering Margaritas after a bit too much Java One partying the night before, they settled down into setting a roadmap for future development. The general consensus was that Smack is already fairly mature and that moderate new developments will continue to enhance the API. Smack 2.0 will focus on a correct implementation of the XMPP protocol rather than the older “Jabber” style protocol. Smack will also continue to track important new extensions to the XMPP protocol developed by the community. These will be implemented as “smackx” extensions or as separate packages. Below is a list of to-do tasks for Smack in rough order of priority:

  • File Transfer (in-band and SOCKS5)

  • Full XMPP compliance for Smack 2.0. The 1.x branch will continue for those using the older Jabber protocol.

  • Allow multiple connections to be serviced by a single thread. This will likely require using NIO. This change would allow Smack to scale to much larger numbers of connections, such as when it’s used in a Servlet for web-based chatting by many people.

  • Use soft/weak references to store listeners. Also refactor smackx classes to not use finalizers to de-register listeners. These changes will make the API easier to use and will protect users against orphaned listener classes.

  • Support more data types in DataForms. Currently, it only supports String values and not other primitive types.

  • Allow users to listen for incoming chats. A “chat” is defined as the first message from a user in a string of messages. The listener should be flexible enough to deal with the fact that not all clients use a threadID for a string of messages.

  • Refactor login method of MUC extension to expose all extra options more elegantly.

  • Improve test case architecture; create a super class for test classes.

  • Use sub-packages in smackx when warranted. For example, org.jivesoftware.smackx.muc. The general rule will be to create a sub-package when there is a substantial number of additional classes.

  • Improve documentation and create a better getting started guide, which should include an introduction to XMPP.

  • Remove GroupChat support in Smack 2.0, since GroupChat isn’t an official part of XMPP and is superseded by MUC.

  • Make improvements to debug console, such as allowing sorting and filtering of packets.

  • Add Rendezvous support, which is the iChat extension to XMPP that uses IP-multicast to discover other clients on the same network. Perhaps this could be submitted as a JEP?

  • Use ANT to make setting the release version number much simpler. Currently, the value must be updated manually in three places.