[Arnt]

When I read the spec the push support was ungood.

What it should do: Tell the server an XMPP or HTTP endpoint to which the server should push a specificed opaque blob when new mail arrives, and possibly other opaque blobs corresponding to other changes, and a (non-binding) rate limit.

With that, it would be easy to write a low-overhead server to support a particular mobile client. Accepts opaque blobs, decodes a little, sends blob to phone via giantmobilevendor.com (which also uses XMPP/HTTP), needs to store no state.

[robn_fastmail]

That's pretty much exactly what it does. Client supplies a HTTP endpoint, that gets called with new state strings. That endpoint arranges for that information to be shipped to the client and then the client issues calls to update methods to get its view of the world up to date.

Its easy to extend to a custom (non-URL) method type if you like, and works well with mobile push channels. This is what we do with our mobile apps at FastMail to push through GCM, APNS, ADM and Pushy.

[Arnt]

Glad to hear you've fixed that, then.