For anyone who's not familiar with APNs, this new protocol is a huge improvement. Since it uses HTTP/2, you can just use an existing HTTP library (which should handle reusing the connection for multiple notifications, too).<p>Here's an example client that I wrote in Go for a client that <i>doesn't</i> have access to an HTTP/2 library. It listens for JSON on stdin. I highlighted the guts:<p><a href="https://github.com/Sidnicious/pushprovider/blob/49b1f63295229e620bc135e8028c3ef88ff81984/pushprovider.go#L53-L107" rel="nofollow">https://github.com/Sidnicious/pushprovider/blob/49b1f6329522...</a>
Has anyone used this successfully yet from Python? It seems like the Hyper library should be able to talk to it, but that comes with a very strong "hyper is in a very early alpha" warning: <a href="http://hyper.readthedocs.org/en/latest/" rel="nofollow">http://hyper.readthedocs.org/en/latest/</a>
While the old binary protocol has its deficiencies, they could have been addressed with relatively minor changes. The plus side with the old protocol is that the message format itself is very simple to generate and parse. Now I have to drag an HTTP/2 library into my notification server and deal with a much more complex protocol where the vast majority of that complexity is completely unnecessary.
This will be very helpful for enterprise environments which have an HTTP proxy for external URLs. I'm guessing this improvement wouldn't need a socks proxy since this is no longer a socket protocol?
The old APNs flow seemed overly complex, especially in comparison to GCM. This seems like a big improvement.<p>Does anyone know why Apple uses certificates instead of API keys (a la GCM) for authorization?