planet.jabber.org

We are working hard on preparing Tigase XMPP Server 5.2.0 release. It is very close as you can guess from remaining tasks list. As you can see we are working on binary packages preparation and installer update. This is necessary as there is lots of new stuff coming to next version. An almost complete list of all changes in version 5.2.0 is on our roadmap page. Almost complete because there will be some new additions to the standard Tigase distribution which are developed as separate projects such as message archiving support (XEP-0136) and... a few surprises....

In the meantime we are releasing 5.1.x update with a few bug fixes and corrections, such as presence update from just subscribed contact of the contact has multiple connections and a few other minor fixes. You can grab binary packages from our project files section.

Here’s the recording our friend Randy from VUC has made of the Jitsi’s presentation on Kamailio World.

Pollymer is a general-purpose AJAX library designed for long-polling any protocol. Before you set off to write manual long-polling code again, consider using Pollymer for the task. Features include:

• Automatic retrying of failed requests, with an exponentially increasing delay between retries.
• Automatic re-polling on success, separated by a small randomized delay. Pass a function for the URL to be able to dynamically adjust the polling target.
• Workarounds for browser "busy" indications.
• JSON-P fallback for cross-domain requests on older browsers (requires server support).

...

Default value:  none Example:  --stats-history=2160,10 Possible values:  SIZE-NUM,INTERVAL_NUM Description: 

The Tigase XMPP Server can store server statistics internally for a given period of time. This allows you to connect to a running system and collect all the server metrics along with historic data which are stored on the server.

This is very useful when something happens on your production system you can connect and see when exactly this happened and what other metrics looked around this time.

The property value consists of comma separated, 2 integer numbers. The first is a size of the buffer. That is how many complete sets of historic metrics to store in memory. The second specified how often to probe metrics on the server.

Please be aware that Tigase XMPP Server produces about 1,000 different metrics of the system. Therefore caching large number of statistics sets requires lots of memory.

Available since:  5.0.0 Author:  Artur Hefczyc Date:  Mon, 2013-04-15 Product:  Tigase XMPP Server

I've been working on Servo for three weeks now. There's an enormous amount of work to do, and I want to capture what's going on and how it's progressing. This should be the first of many such updates on the project.

Day One

When I arrived, Servo no longer built at all, at least not on OS X. Servo often requires bleeding edge versions of Rust, and backwards incompatible changes to Rust are still happening on a regular basis. Since all of the contributors to Rust work on different platforms, when porting to a new Rust compiler, some platforms have gotten left behind. This was particularly acute this time because Rust 0.6 contained a lot of syntax changes, mostly things that got removed from the language, and many pieces of Servo were using syntax that was deprecated in Rust 0.5, and was finally deleted entirely in Rust 0.6.

Upgrading to Rust 0.6

Rust 0.6 removed a lot of keywords and syntax from the language. Porting Servo required modifying all the constants, many function declarations, many import statements, etc. These changes were largely mechanical. There were a few changes that weren't so easy.

Mutable fields are being removed from the language, and mutability will be controlled by the mutability of the struct itself. Not all of these had to be removed in Servo, but many of them did, and removing them often required slightly changing the data structures and their type signatures. In some cases this was trivial, but in a few cases these changes needed more care. In particular, lots of these changes bumped up against the Rust borrow checker, which ensures it's safe to hand out pointers to memory. There are still some bugs in the borrow check, and workarounds are not always straightforward.

It took me about a week and a half to work my way through all the dependent libraries and Servo itself at which point I had a build. By the end of that second week I had landed the language upgrade to servo as well as some Rust library changes that were needed. The end result is that Servo is now using Rust 0.6 syntax, but it requires a post-0.6 version of Rust due to the Rust changes not landing quite in time for the 0.6 release.

GPU Rendering

Servo uses many forms of parallelism, but one bit of low hanging fruit is to move to a fully GPU rendering path. Currently compositing is done on the GPU, but rendering to the various layers is done on the CPU. This is how most current browsers operate as well.

We're moving to rendering on the GPU as well which should speed up some things a bit. Instead of rendering in parallel to several layers, Servo will render directly into textures on the GPU which the compositor can use without doing CPU to GPU memory transfers.

This required upgrading the rendering stack to a newer version of Azure (Mozilla's drawing library) and a new version of Skia (the specific backend that Azure uses on OS X, Linux, and Android). Now that this part is done, we'll be adding texture layers to the renderer and switching drawing to those.

Automation

We're setting up build and testing automation for Servo now, which should help ensure Servo remains buildable on all platforms. Rust has an amazing set of tools for this already, which we are hoping to reuse fully. Buildbot machines run builds and tests, and a GitHub bot called Bors handles dispatching builds for patches that have been reviewed and merging pull requests that have passed tests.

For now this work will be on Linux, but we hope to expand it to cover OS X and Android as well in the near future. Once Servo is a little farther along, we plan to put up nightly snapshots so more people can follow along with our progress.

Other Work

There's tons of other work in progress on both Servo and Rust. The DOM bindings are getting improved, a new Rust scheduler that will make performance and I/O better is in progress, a more optimized C FFI in Rust should also land soon, and the rustpkg package manager is shaping up which we'll be switching to for more and more of Servo as it matures.

We need more help in lots of areas. Please join us in IRC in #servo or on the mailing list. We'll be trying to mark bugs and projects that are well suited for new contributors. If you want to work on Servo and write Rust code all the time, we're hiring.

If you are a student excited by XMPP, high-performance and Erlang, this should be great news.

It means that you will get the opportunity to get funded by Google to work on Erlang open source projects during the summer. Among exciting projects to work on, you will find:

• ejabberd, the robust, scalable, large scale and ubiquitous XMPP server
• Elixir, a programming language build on top of Erlang Virtual Machine.
• Tsung, the power tool for large scale benchmarks.
• Zotonic, the scalable and high-performance content management system.

ProcessOne will be focusing on mentoring XMPP, ejabberd and Tsung projects. This will be a great opportunity to work with more than 10 years Erlang, XMPP and performance veterans (yes, all at the same time).

Students applications will be closing on the 22nd of April.

More details on Google Summer of Code website and on the Beam Community Github.

Next week (April 17th 2013) we will be at the Kamailio World Conference in Berlin. Other than the many interesting talks and demos there, you’ll be able to also see a presentation about Jitsi, CUSAX, libjitsi and Jitsi Videobridge.

Update: Due to internal feedback, it was decided to delay the commercial plans for indeterminate time.

After almost four year of development, we are proud to announce that yaxim, our Open Source XMPP client, is sufficiently mature to fulfill even the needs of large corporate customers. And like with any project that grows from your garage to become a viable product, the day comes when its commercial future needs to be set.

Starting Tuesday, yaxim will adapt its pricing to the competitive levels set by the Mobile Network Operators with their new Rich Communication Services (also known as joyn™). However, there is no need to worry. For most of our loyal customers, the free Basic plan will be more than sufficient. For other customers, we offer the Standard, Advanced and Professional plans at reasonable monthly rates.

With the beginning of the next business week, the following pricing model will be rolled out (all prices are in US Dollar, international offers will be scaled appropriately). All users will automatically be enrolled in the Basic plan, and have the option to purchase additional messages and roster capacity or switch to one of the paid plans via in app purchase.

Basic plan (free)

The Basic plan includes all that is needed for most users, and it is free!

Included1)Additional Roster Groups31.00$ / group Roster Entries151.00$ / 10 entries Message Sending 50 / month 0.19$ / message Message Receivingunlimited2) Files / Images5 / month0.39$ / file or image Encrypted Messagesnot supported

1) Unused units expire at the end of the calendar month.
2) Receiving messages is not limited, but no notifications will be displayed after you received 50 incoming messages.

Standard plan (5.99 $ / month)

The Standard plan includes the typical amount of messages for more sophisticated users, at a reasonable rate.

Included1)Additional Roster Groups101.00$ / group Roster Entries1001.00$ / 10 entries Message Sending500 / month0.09$ / message Message Receivingunlimited2) Files / Images50 / month0.19$ / file or image Encrypted Messages50 / month0.19$ / message

1) Unused units expire at the end of the calendar month.
2) Receiving messages is not limited, but no notifications will be displayed after you received 500 incoming messages.

Advanced plan (14.99 $ / month)

The Advanced plan is meant for users who value their communication privacy.

Included1)Additional Roster Groups200.50$ / group Roster Entries3001.00$ / 50 entries Message Sending1000 / month0.05$ / message Message Receivingunlimited Files / Images200 / month0.09$ / file or image Encrypted Messagesshare the limit with standard text messages

1) Unused units expire at the end of the calendar month.

Professional plan (39.99 $ / month)

The Professional plan provides unlimited communication freedom.

Included Roster Groupsunlimited Roster Entriesunlimited Message Sendingunlimited Message Receivingunlimited Files / Imagesunlimited Encrypted Messagesunlimited

Default value:  ALL Example:  --domain-filter-policy = LOCAL Possible values:  ALL|LOCAL|OWN|BLOCK|LIST Description:  The property is a global settings for setting communication filtering for vhosts. This function is kind of extension of the same property which could be set on a single user level. However, in many cases it is desired to control users communication not on per user-level but on the domain level. Domain filtering (communication filtering) allows you to specify with whom users can communicate for a particular domain. It allows to restrict communication for a selected domains or for the entire installation. A default value ALL that users for the domain (by default for all domains) are allowed to communicate with any user on any other domain. Other possible values are:

1. ALL a default value allowing users to communicate with anybody on any other domain, including external servers.
2. LOCAL allows users to communicate with all users on the same installation on any domain. It only blocks communication with external servers.
3. OWN allows users to communicate with all other users on the same domain. Plus it allows users to communicate with subdomains such as muc.domain, pubsub.domain, etc....
4. BLOCK value completely blocks communication for the domain or for the user with anybody else. This could be used as a means to temporarily disable account or domain.
5. LIST property allows to set a list of domains (users' JIDs) with which users on the domain can communicate.

This is a global property which is overridden by settings for particular vhost.

A default settings for all virtual hosts for which the configuration is not defined. This settings is useful mostly for installations with many virtual hosts listed in the init.property file for which there is no individual settings specified. It allows to configure a default values for all of them, instead of having to provide individual configuration for each vhost.

It is also applied as a default value for all new vhosts added at run-time. Available since:  5.2.0 Author:  Artur Hefczyc Date:  Sun, 2013-03-10 Product:  Tigase XMPP Server

Default value:  <null> Example:  --s2s-secret = some-s2s-secret Possible values:  ascii string Description:  The property is a global settings for s2s secrets to generate dialback keys on the Tigase installation. By default it is null, which means the secret is automatically generated for each s2s connection and handshaking.

This is a global property which is overridden by settings for particular vhost.

A default settings for all virtual hosts for which the configuration is not defined. This settings is useful mostly for installations with many virtual hosts listed in the init.property file for which there is no individual settings specified. It allows to configure a default values for all of them, instead of having to provide individual configuration for each vhost.

It is also applied as a default value for all new vhosts added at run-time. Available since:  5.2.0 Author:  Artur Hefczyc Date:  Sun, 2013-03-10 Product:  Tigase XMPP Server

Default value:  tigase.cluster.repo.ClConSQLRepository Example:  --cl-conn-repo-class = tigase.cluster.repo.ClConDirRepository Possible values:  class implementing ComponentRepository Description:  This property allows to set class controlling cluster connections repository. The cluster connections repository is responsible for discovering cluster nodes which are part of the installation. Tigase in cluster mode establishes TCP/IP connections between cluster nodes to allow for user communication and exchanging cluster state metadata.

From the Tigase XMPP Server 5.2.0 the server supports cluster auto-configuration so no action, configuring or any maintenance action is required to add a new cluster node.
As everything in the Tigase it is also a pluggable system so it is possible to implement/add new ways to synchronize information about cluster nodes on the system. Currently following cluster connection repositories are implemented:

1. ClConSQLRepository a default implementation which synchronizes cluster nodes information through SQL database. By default it uses the same database as the main Tigase DB, that is the UserRepository database. All the cluster nodes need an access to the same database for cluster nodes information synchronization.
   For backward compatibility this mode reads the list of the cluster nodes from a configuration file (init.properties) as well. However, this is used only as an initial setup and, after startup time the cluster nodes are synchronized through the database.
   It is recommended however, that the '--cluster-nodes' property is not used (should be removed or commented out) when the automatic reconfiguration mode is used. This is because we found out that when the network configuration and DNS names are not perfect than automatic mode may conflict with manual settings.
   By default the same database as for the user repository is used for the cluster automatic cluster mode but, a different, separate database can be used as well. A DB URI for a different SQL database can be set using following configuration property: cl-comp/repo-uri=jdbc:mysql://localhost/tigasedb?user=user&password=mypass
2. ClConDirRepository an alternative way to synchronize information about cluster nodes on the installation through filesystem. This might be used in case where DB is not accessible by the clustering code for some reason or synchronization through DB is not desired.
   To make use of the filesystem based cluster nodes synchronization you need to mount a directory via some network filesystem mechanism (like NFS for example) and point the Tigase to the directory. The rest works the same way as through the DB. However, instead of writing cluster node metadata to some DB table, each node writes it's metadata to a separate file in the given directory.
   This mode is also compatible with the manual nodes configuration through '--cluster-nodes' but the same precautions and suggestions as for DB based automatic node hold.
   A default location of the directory is probably not very useful, as it points to etc/ directory, therefore, normally a correct location has to be set through the repo-uri property in a following way: cl-comp/repo-uri=/mount/tigase-cluster-repo
3. ClConConfigRepository is an implementation which allows you to revert back to the previous and manual cluster configuration through '--cluster-nodes'. However, since version 5.2.0 the '--cluster-nodes' has been extended with ability to set password and port number for each cluster node.

Available since:  5.2.0 Author:  Artur Hefczyc Date:  Wed, 2013-03-20 Product:  Tigase XMPP Server

Dan York interviews Jitsi project lead Emil Ivov about IPv6 and DNSSEC support in Jitsi. As most of you probably know, Jitsi has been supporting both IPv6 and DNSSEC for a long time now. In the following video Emil explains how it all started and what value DNSSEC brings to VoIP.

We are announcing two major changes in ejabberd development today:

• a new version of ejabberd, called ejabberd Community Server (eCS), as opposed to ejabberd Business Edition (eBE)
• a change in version numbering, and thus our workflow

 

Both ejabberd editions are targeting different goals and audience:

• ejabberd Community Server is open source code, in an effort lead by ProcessOne as always, and supported by contributions coming from all horizons. The project is community driven and focus on the kind of features, innovations and experiments that are expected from an open source project
• ejabberd Business Edition targets carriers, websites, service providers, large corporations, universities, game companies, that need high level of commitment from ProcessOne, stability and performance and a unique set of features to run their business successfully

ejabberd Community Server

ejabberd Community Server, released today in beta, provides huge improvements regarding performance and memory consumption. It will be an excellent basis to accelerate the community development effort. This release switches internal representation of data from list to binary to reduce memory consumption, all over ejabberd code.

For those interested in technical details, ejabberd started its existence using list to represent string, as it was the available approach at this time. It was causing increased memory consumption, but at that time there was also other limiting factors on less powerful servers (like CPU consumption use by the TCP/IP connections themselves).

Erlang now allows the use of binaries, which reduces the memory consumption, but ejabberd didn’t adopt this solution yet because it involved many changes in the code. That major change was delayed for ejabberd 3.0.0-alpha attempt, which used the new exmpp library and binary representation. However, the switch to exmpp library involved not only a major representation change, but also an enormous major and unnecessary API rewrite; not only in ejabberd core, but also in all the modules and all the contributed modules. So, we stepped back to use a more adequate method and the usage of exmpp in ejabberd internals has been deprecated.

There is a new ejabberd master branch, which comes from taking the good 2.1.12 and converting it from using strings to binaries. No other major changes. Simple and concrete. This is just performance improvements and internal changes that makes it possible for the community to happily build the next features.

New versioning scheme

Along with this new release comes a new versioning scheme. Ten years ago, ejabberd 0.1-alpha was released. Three years later, ejabberd 1.0.0 appeared with full XMPP compliance. And two years later, ejabberd 2.0.0. And after two more years, ejabberd 2.1.0.

Those major releases included big and small features, improvements and bugfixes just like the periodic minor releases. They never introduced unstability or major API changes: they were numbered as major versions only because it was time to increase the version number. In practice, improvements and bugfixes are introduced as they are available, efficient and stable, without considering if it’s a major or minor release.

The problem we had is that we had been referring internally to ejabberd3 as the commercial version. ejabberd community server was akwardly stuck in a 2.x version numbering.

To solve that problem, we decided to switch to an Ubuntu-like version numbering for ejabberd community server. The next releases will be numbered as “Year.Month-Revision”, instead of ”Major.Minor.Bugfix-Revision”. It will reflect more precisely how we work. You can thus expect a change in our worfklow and more interim stable releases in the future.

In conclusion, three years after the last major ejabberd release, we are pleased to announce ejabberd 13.03-beta1 and we are sure you will all love the changes.

 

Where to find the source code

You can find it in usual places:

• Code source is developed on ProcessOne Github account: ejabberd on Github. If you had the old master branch, please, delete it to avoid git pull problems (as it has been moved).

Please, do not hesitate to watch, star, clone the repository on Github.

• ejabberd page on ProcessOne website.

There is an incompatibility issue between the current version of Pontarius XMPP and jabber.org, where jabber.org (running M-Link) expects a top-level namespace of “jabber:client”, like so:

<stream:stream to='jabber.org' version='1.0' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'>

However, RFC 6120 states that client implementations only MAY declare such a default namespace. Implementations are also free to open the stream without declaring xmlns='jabber:client', and instead declare xmlns='jabber:client' on every child element. This is semantically equivalent, and is a MUST requirement of RFC 6120.

It would be nice if Isode/jabber.org could update its software to conform with this part of the standard.

Also, the XML for errors generated for namespace errors is broken. If we send <stream version="1.0" to="jabber.org" xmlns="http://etherx.jabber.org/streams">, the server will return with a stream error element and a closing stream tag that are not preceded by an opening stream tag:

<stream:error><bad-format xmlns='urn:ietf:params:xml:ns:xmpp-streams'/></stream:error></stream:stream>.

(On a side note, jabber.org/M-Link does not include a language tag in its stream element, which is a MUST requirement of RFC 6120.)