The first release of the project defines the codebase for Tinder. Duplicate code will be removed from Openfire and Whack. This code will be the base for Tinder.
Community members are invited to identify code within other projects that can be moved to Tinder.
The emphasis in this stage will be put on portability. Some code will need to be changed (such as package names including identifiers like “openfire”), but this will be avoided where possible
Release 1.1: Concurrency
The code in the Tinder project is a very low-level implementation of XMPP objects. As usage of these objects is wide-spread, extra care should be given to robustness of the code. This release will focus on Java concurrency (threading) issues.
The existing documentation will be modified where needed, to explicitly include thread-safety and other concurrency characteristics. Additionally, JSR 305-style annotations will be added, to further identify the applied concurrency strategies.
Where appropiate, class implementations will be modified, to help prevent concurrency-related problems in code that depends on Tinder. Modifying the JID class to be an immutable class is an example of such a change.
Release 1.2: Building blocks
One of the features of Tinder is an XMPP component definition. Although components can be created in a variety of ways, we’ll introduce an abstract implementation. This implementation will provide a robust, scalable component implementation that can be extended easily. Using this implementation, developers will be enabled to develop custom, feature-rich but robust components with hardely any effort.
Release 1.3: Managing & Monitoring
Various parts of the Tinder library can be managed and monitored programmatically. This release will add new features, mostly based on JMX technology, that enables you to better tune your application.