kobit's blog

I am happy to announce release of a new version of the Tigase XMPP Server. This is the first version of the 5.x line and the code is still under intensive tests. As most of the tests are already passed and the code runs on a few live installations I consider this to be Beta ready.

Packages are available from the download page. As usually the test page has been updated with automatic tests' results for the published version.

Changelog list is quite long and modifications fall into a few categories:

Protocol:

1. A new implementation for handling external components connections, supporting XEP-0114, XEP-0225, with protocol auto-detection, multiple connections on a single port, multiple connections for a single external domain, etc…..
2. Full support for stringprep added. The use of the full stringprep processor is optional (off by default) and the JID processing can be changed via pluggable framework. 3 processors available now: full stringprep - very resources expensive, simple (regex based) - default, empty - no processing at all.
3. Roster changes: fixed issue with buddy name set to 'null' in some cases , multiple roster elements are now allowed for set requests, stringprep optimisations, support for extended buddy information to be stored with roster data in DB.
4. Fixed a problem with s2s connections for external components connected to the server - they are automatically detected by s2s component and all the traffic is routed properly
5. Fixed problem with not sending stream closing tag in some cases when the connection to the client is closed
6. Fixed rare issue occurring if there are multiple user connections with the same resource that the older connection with the resource was not closed.
7. Number of bug fixes and optimisations in s2s implementation, still no TLS support yet though.
8. Stream compression can be now activated at any time, it is up to the client to decide

Administration:

1. Server configuration code reworked, fixed an old issue with init.properties and tigase.xml configuration files, tigase.xml is no longer used by default (still possible though), configuration can be stored in the database and configuration management available via ad-hoc commands and scripting API.
2. Configurable packet filtering for every component separately can be loaded as plugins (and API)
3. MySQL schema and stored procedures updates for UTF-8 encoding, changed a last_login, last_logout fields default values from 0 to some correct and sensible value.
4. To overcome problems with packets order on some system there is a configuration option to not use priority queues which may sometimes cause packet reordering.

Development:

1. Scripting API reworked, this is not the server built-in core feature and the scripting feature is now available to all components automatically
2. Component repository API - an easy to use framework for tigase component developers to store certain kind of data in database - the data can be also manipulated via ad-hoc commands and scripting
3. Added secure logging mode for XMPP stanzas to prevent privacy issue - XML element CData is replaced with text: 'CDATA size: NNN'
4. A new API for component tasks added - based on Java TimeoutTask but a single thread controls all the component tasks
5. Lots of JavaDoc documentation has been added and online guides on the website
6. All the core Tigase code to use new JID and BareJID classes instead of String
7. Packet API changed to optimise ways stanza to/from addresses (JIDs) are used.
8. New SM plugging processors API introduced and an abstract class which make it very easy to follow packet flow. This is to avoid confusing detection where from, where to the packet is going (from the user, to the user, to the server….)
9. User registration code changed to allow for storing any kind registration data, the user can provide an extended form with additional fields and they all are stored in the DB

Normally you would not call something a load test if there are just 40 user connections opened to the server.

This time, however the Tigase was running on the mobile phone which is itself an interesting achievement. One thing, however is to just run the application and another is to actually make it do something useful.

The Tigase running there was just the standard version you can download from the website, no single line of code was changed. And also the N900 was running all the standard applications as a fully functional mobile phone.

The only change I made to the phone was installation of the JRE and Bash shell, the rest remained unchanged and none of applications running on the phone was stopped.

All the connections to the server were established via mobile network and all the connections were encrypted with TLS.

 I am at the XMPP Summit/FOSDEM now. Thanks to people form Nokia we have an opportunity to play and run some software on N900 devices and thanks to Florian from Flosoft we have SIM cards for data transfer.

What is the most tempting thing for the software developer? Well, at least for me is to run my software on any possible device.

Taking the opportunity to use N900 and play with it I just had to try to run Tigase on it. I have already tested Tigase on small computers, Netbooks with ATOMs and small amount of memory. Tigase passes all tests when run with 10MB of memory so I was pretty sure N900 has enough memory and power to run Tigase.

I have added a project tracker for the Tigase XMPP Server. It is based on the Drupal Storm module.

The good thing is that it is very well integrated with the website. I am going to add trackers for other sub-projects as well (MUC, PubSub, etc...), they can use Drupal accounts, tickets can be moved between trackers and we have all the development related stuff in one place. I hope it works well.

On the other hand, please note, this is a very new feature on the website so consider it as an experimental stuff and report any problems you may encounter. If you have any suggestions or ideas please let me know.

Right now it offers only basic features and I am going to add more in time.