Over the past few weeks, I have been looking at Funambol, the open source mobile data synchronisation server. I started by looking at the features, history and requirements, and followed up with a full guide to configuring the data server for mobile contact and calendar synchronisation. I hope readers found the guide useful, and if you have configured a server of your own, it would be great to hear about the ways that you have been using it.

I mentioned in my first analysis that Funambol claims to offer push e-mail services–I used the word “claims” because of the following extract from their main Web page:

“Funambol is open source mobile application server software that provides push email, address book and calendar (PIM) data synchronization, application provisioning, and device management for wireless devices and PCs, leveraging standard protocols. For users, this means BlackBerry-like capabilities on commodity handsets.”

” Funambol consists of: Funambol Data Synchronization Server: a mobile application server providing synchronization services for wireless clients and PCs, including push email.”

“The Funambol project is intended for IT professionals looking to leverage the latest generation of mobile devices for email and PIM.”

This would all lead one to assume that after installing and properly configuring Funambol–corporate push e-mail would be a reality. After reading the installation and admin guides, I was a little bemused because I couldn’t find any reference as to how push e-mail is configured and implemented; I continued with the installation, regardless, as the contact and calendar synchronisation would in itself be very useful.

After joining the Yahoo Sync4j tech group, I noticed that quite a number of people were posting questions regarding push e-mail. After all, this is the feature that everybody wants! While reading through the archived posts trying to find out exactly how push e-mail can be configured, I came across one conversation which helped to explain quite a lot:

 

“I can’t belive that this is the only way to notify the device.

If each time that something changed a message is send by an

sms service this could be very expensive.

 

Are there other possibilities to notify the device. Perhaps the

commercial version have other inbuilt features to push the email.

 

I don’t understand why all around the web is written that funambol

is a opensource software to push email and the software don’t contain

a ready to use module for this feature.

 

It is nearly the same that if you buy a car and if you want to drive with the car you first have to buy or to build the wheels.”[sic]

Jason Finkelstein the Funambol Community Manager came back with some answers:

“Please be aware that Funambol v3 is the first Funambol release that supports push e-mail. It is based on the SyncML 1.2 standard that supports push e-mail and it provides two methods for push e-mail notification: SMS and TCP/IP. These methods enable mobile carriers to provide push e-mail notification for end customers. If you are not a carrier, you have a few options:

> You can use the TCP/IP push, which is the best option to minimize battery consumption and bandwidth usage, BUT some carriers might block it. So, this method requires carrier cooperation.

> If that does not work, you can use SMS push. As you indicated, this might cost you, unless you send/receive very few emails per day or you have an unlimited SMS message package. This approach should work with all carriers, but again, some might still opt to block it (as you can tell, carriers are very protective of their data networks).

> If that does not work, I recommend you do scheduled pull (e.g., every 15 minutes). This approach would consume more battery, but would depend on how many emails you receive. If you get 1 email/minute and you pull every 10 minutes, you will actually consume 1/10 of the battery with pulling instead of pushing. Of course, this experience is not as cool as push, but I personally feel it to be good enough.

Unfortunately, Funambol (like all others) is limited by strict carrier network policies. We are also working on a solution to go around the carrier limitations on TCP/IP push and we hope to have some news soon. We welcome any input that you (or others) have on approaches that should be considered.”

I questioned Jason further asking how/why mobile operators block the push functionality of Funambol; he followed up with:

“For security reasons, carriers might prevent anyone outside their network from accessing the devices on their network. That is quite understandable. Obviously, for Funambol, it is not a problem since we deploy our solution at the mobile operator site, inside their network. But, if you are deploying the Funambol Community Edition within an enterprise, you might have to discuss it with the carrier directly.”

I take this to mean that for end users (personal or corporate use) true Blackberry-like push e-mail isn’t a possibility—the option open to these types of users is WAP/SMS push, as implementation of TCP/IP push email is limited to mobile carriers.

I had no idea what WAP/SMS push actually meant but after a little research, I found that it’s quite a simple process: the data server receives an e-mail via the imap/pop3 connectors and then sends an SMS notification to the device which prompts the device to connect back to the server and pick up the waiting mail. For low volumes of e-mail this could be acceptable, but when volumes start to increase, this will start to become quite expensive (unless you have an unlimited SMS package with your mobile provider). As for using a scheduled pull, this could indeed still be the best option—however, there is no need to use Funambol to implement pull e-mail; most mobile phones can collect email from IMAP and POP3 accounts directly from the mail server.

In conclusion, I would say that for corporate or private users, Funambol offers a great way to keep contact and calendar information synchronised between a variety of different devices and applications—however, its usability for push e-mail is somewhat limited, and one would probably be better off using the device’s native client with an IMAP account or biting the bullet and subscribing to a Blackberry service.