Good news! Opush is moving forward and the next release will hopefully bring many major changes.
This version is in its last stage of developpement and we already use it internally, you can follow improvements at [ci-obm.linagora.com/stash/projects/OBMFULL/repos/opush](http://ci-obm.linagora.com/stash/projects/OBMFULL/repos/opush/browse).
Interested? So let's talk about some of them!
## Moving Opush out of the OBM build process
The OBM Core-Team often discusses some annoying Opush bugs with OBM users.
The issue for our team is that most of time those bugs are already fixed in an upstream version and people cannot enjoy it!
Despite those bugs, administrators do not want to update their whole installation because other features or components work like a charm.
To provide the best quality of service to our users, we want to release Opush as fast as possible and remove the constraints slowing this process.
Previously the release workflow was really tied to the OBM one, but now Opush has become standalone and users can enjoy its latest version with an older OBM!
We will also keep the compatibility with every [OBM versions newer than 2.5.7 along releases](http://obm.org/blog/obm-257-release).
The packaging has been totaly remade but you will be able to transparently upgrade from the integrated version to the standalone version.
The new Opush will have its own repositories:
* [http://deb.obm.org/opush/stable](http://deb.obm.org/opush/stable) (latest stable version)
* [http://deb.obm.org/opush/testing](http://deb.obm.org/opush/testing) (testing version prior to the release)
* [http://deb.obm.org/opush/unstable](http://deb.obm.org/opush/unstable) (heavily changing, use at your own risks)
## Opush meets a so pretty NoSQL database
Opush was using a component named EhCache to persist its data on the filesystem.
It offers really nice performances and useful features for the kind of data we were storing.
Unfortunately, this component has some limitations:
* Weak durability
Ehcache data files cannot be read until the index files are created and those files are only written at shutdown.
In case of crash or kill the indexes are never written and Opush loses all its knowledge.
* Not compliant with High Availability
As its data files are unreadable without a clean shutdown, no replication is possible for an active/passive architecture.
Unless you use the non-free version, EhCache cannot be scaled.
Active data is written into the JVM's memory using EhCache, so
it cannot be accessed by another application running into another JVM.
Fortunately, we are changing the way used to store data, Opush is getting rid of EhCache for the pretty Cassandra!
As Cassandra is a decentralized NoSQL database you will have to deploy and maintain new servers.
A single Cassandra server is enough to make Opush work but you will not have every benefits of a Cassandra cluster. If you want the strongest architecture you will have to deploy more nodes to have durability, fault-tolerance and elasticity.
Each node must run with 2GiB of RAM and a JAVA 7 SDK, the documentation can be found [here](http://www.datastax.com/documentation/cassandra/2.0/index.html).
## Next roadmap target
The best coming enhancement is that Opush will be scalable and highly available.
As no information will be kept locally on the node used to synchronize a device, you will be able to create as many Opush nodes as you need to fulfill synchronization requirements of your enterprise. In other words Opush capacities will grow with your company.