Check the client with similar interface for Google Cloud Messaging.
Standard library has support for SSL transport. However, it is impossible to use it with certificates provided as a string. We store certificates in database, because we handle different apps on many Celery worker machines. A dirty solution would be to create temporary files, but it is insecure and slow. So, we have decided to use a better OpenSSL wrapper and pyOpenSSL was the easiest to handle.
- Support certificates from strings. We do not distribute certificate files on worker machines, they fetch it from the database when needed. This approach simplifies deployment, upgrades and maintenance.
- Keep connections persistent. An SSL handshaking round is slow. Once connection is established, it should remain open for at least few minutes, waiting for the next batch.
- Support enhanced format. Apple developers have designed a notoriously bad push protocol. They have upgraded it to enhanced version, which makes it possible to detect which messages in the batch have failed.
- Clean pythonic API. No need for lots of classes, long lists of exceptions etc.
- Do not hard-code validation, let APNs fail. This decision makes library a little bit more future proof.