Handle multiple sets of credentials with a single ApnsClient instance

Now that we’ve introduced connection pooling in #492, the next big step will be to get clients to choose connections from different sub-pools depending on the topic to which a notification should be sent (and therefore which credentials the client should use). To get there, we’ll probably need to introduce some abstract notion of ApnsCredentials that has subclasses/implementations for X509 certificates and PKCS#8 signing keys, and then extend the existing connection pool infrastructure to add “keyed” pool functionality.

The end result will be that callers will only need to have a single ApnsClient instance for all of their destination apps, which will probably be a big win for high-volume users.

[jchambers]

It’s the next major feature planned, but there’s isn’t a specific timeline for release.

[aptituz]

Just some cents from a user about the KeyedPooledObjectFactory topic above:

We could build everything around topics, which would be reasonably simple and straightforward, but maaaaay introduce some unnecessary overhead in cases where people are sending to lots of topics with the same credentials. If we keyed based on credentials instead, we’d have connections allocated per credential set rather than per topic.

We are one of those users having several topics with the same keys. Thus, I think it wouldn’t be ideal to have connection pools per topic (but of course I may be biased here). In case its of any worth for you: in our service we have the concept of an app-group and topics are mapped to app-groups. Maybe a similar concept would be helpful for pushy?