This can't quite be accurate, because Server/Exchange ActiveSync is done entirely over HTTPS.
The question is if EAS can use two HTTPS connections -- one over GPRS for notification, and one over WiFi to actually perform the sync. I'm guessing no, and that the icons are wrong.
I've just stumbled in here from a Google search - I have an iPAQ hw6915 set up with push email and it seems to work quite well, except for the WLAN/GPRS integration - or lack of it!
EAS with the hw6915 (or any other GPRS/WLAN WM5 phone?) offers the potential for big savings versus BB as I am sure that a significant proportion of the traffic is delivered when users are in range of a WLAN.
Right now if you set EAS to "as items arrive" then all traffic seems to be routed to GPRS regardless of whether WLAN is active or not, but if you change the schedule to any specific interval then it seems to route over WLAN if available.
The gotcha is that once the iPAQ goes into standby (5 minutes max when on batteries) the WLAN is gone and it reverts to GPRS, and when it wakes up it starts syncing (over GPRS) before the WLAN is back up. Since the minimum specific interval for sync is 5 minutes, you are almost guaranteed to be in standby!
Wouldn't it be much better if you could use GPRS for notification as items arrive and WLAN (if available) for the sync, with a short delay to allow any WLAN connection to come back up?
EAS with the hw6915 (or any other GPRS/WLAN WM5 phone?) offers the potential for big savings versus BB as I am sure that a significant proportion of the traffic is delivered when users are in range of a WLAN.
Not only that, it offers the ability to use EAS when you're in weak coverage. At one point, I was using my JasJar with a carrier using SMS push; even if the JasJar was in an area with a too-weak signal for GPRS, as long as the SMS came through the device could wake up and sync over WiFi. (This was before the MSFP was installed on the device, which changes the behavior of "as items arrive". And I think that was what was happening, although I didn't test it extensively. I do know the SMS-based push algorithm entailed the device actually waiting before triggering the AS, by design.)
Quote:
Wouldn't it be much better if you could use GPRS for notification as items arrive and WLAN (if available) for the sync, with a short delay to allow any WLAN connection to come back up?
Yes, it could be very convenient. I think this may become a reality when UMA starts becoming more prevalent, allowing seamless handoffs between WiFi and cellular data. On the other hand, as 3G, 3.5G and 4G hit the market and more unlimited plans come into effect, the benefit of WiFi diminishes immensely. My 700w is sufficiently fast over EVDO that dealing with the "hassle" of WiFi (association time, amongst other things) is just not worth it.
Yes, it could be very convenient. I think this may become a reality when UMA starts becoming more prevalent, allowing seamless handoffs between WiFi and cellular data. On the other hand, as 3G, 3.5G and 4G hit the market and more unlimited plans come into effect, the benefit of WiFi diminishes immensely. My 700w is sufficiently fast over EVDO that dealing with the "hassle" of WiFi (association time, amongst other things) is just not worth it.
--janak
I wouldn't have thought it beyond the skills of MS to come up with a utility that could figure out that if it can talk to the specified Exchange server over WLAN it should use that rather than GPRS/EDGE/EVDO or whatever. But it does need to be automatic - if there is hassle people will not bother.
I would guess that a lot of the Blackberry traffic (more than half?) is probably delivered when people are in their offices, almost certainly in range of a WLAN connected pretty directly to their Exchange server. Even when you are out of the office, you are frequently in range of a public WLAN, so it could at least try that route first.
Why pay your operator to deliver it - and before you say "unlimited" in my book there are no free lunches - if it is truly unlimited you are probably paying too much, and if it has a limit then by sensible use you could probably find a cheaper plan with a lower limit.
A lot of us would not be jumping through these hoops if BB was reasonably priced, so price is important here, and MS should take advantage of being the knight in shining armour for once in their existence and put the finishing touches to the job!
Why pay your operator to deliver it - and before you say "unlimited" in my book there are no free lunches - if it is truly unlimited you are probably paying too much, and if it has a limit then by sensible use you could probably find a cheaper plan with a lower limit.
Another reason why I think this would be a good idea is because whilst you may have an unlimited data package, it is typically only covered if you are in your "home" country. If you are in a roaming situation, you end up paying for it, typically around $14 per MB.
Not nice.
So any opportunity to offload that onto what might be a cheaper transport system would be of benefit.
Why pay your operator to deliver it - and before you say "unlimited" in my book there are no free lunches - if it is truly unlimited you are probably paying too much, and if it has a limit then by sensible use you could probably find a cheaper plan with a lower limit.
I don't call it a free lunch, but I wouldn't go back to limited data. T-Mobile offers unlimited data and WiFi for $30/month, with pretty much no catches. Alas, I use Verizon, which is more expensive, but it's also quite fast.
I think Philip outlines an excellent point for WiFi, though. Unfortunately, the mobile team at Microsoft often has to tradeoff features in the interest of actually shipping product, and I haven't seen seamless support for multiple connection types at the top of the featurelist. However, that's for shipping OSes; it's possible Microsoft is working on this for future OSes. If the opportunity does arise, I will chat with the MS folks about it. I do think UMA will gather attention and drive support.