Wanted: (Component writing) guinea pigs!

Tinder
1

Hello all,

For the next release of Tinder, we’re working on an abstract implementation of the Component interface, as described in TINDER-16. I’ve copy/pasted the description of that issue here for your reading pleasure.

A lot of the work that goes into writing a Component
interface is repetitive work. Tasks like Stanza handling, Service
Discovery processing and error handling are often duplicated between
implementations in the form of boilerplate code. Some of this
functionality, such as making sure that every IQ request is being
responded too, is easily overlooked, causing the component to break the
XMPP specification.

For example, these two things go wrong in most Component implementations that I came across:

  • The XMPP specification states that every IQ request (type get and set) must be responded to by an IQ response (error or result). It’s all to easy to implement a Component that does not do this dutifully.
  • If used in Openfire, the same thread that feeds a Packet to the Component is often used to process the stanza inside of the implementation. If just one Component adds a delay, Openfire is guaranteed to crumble under load. If ran in a cluster setup, the entire cluster is very likely to die.

Problems like these are easily overcome by using an abstract implementation of the Component interface, which includes all of these features.

The abstract implementation that’s the subject of this issue is not intended to be a “one size fits all” solution. Instead, we should advertise the implementation as kind of a “this is how you should write a component, using this” approach. The implementation is a good way to go with it because it’ll get people going in the right direction and if they find they outgrow what Tinder provides, they now can look back at it and know what they need to implement.

We’re looking for developers (preferably but not necesarily having experience in writing components) to give this implementation a try. Any feedback that will help us to improve on the presented solution would be very welcome.

The implementation of the abstract component can be found in the subversion trunk of the Tinder project. You can access the source as described on the source code download page of IgniteRealtime.org.

Looking forward to your thoughts and ideas!