Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wish list #42

Open
1 of 11 tasks
nathany opened this issue Apr 30, 2015 · 0 comments
Open
1 of 11 tasks

Wish list #42

nathany opened this issue Apr 30, 2015 · 0 comments

Comments

@nathany
Copy link
Contributor

nathany commented Apr 30, 2015

There are a number of things I would like to see:

  • Separate loading certificates from configuring the Client or Feedback service, and add support for *.p12 DER certificates as exported from the Apple keychain. Add support for p12 files #37

  • Separate the serialization and binary encoding of payloads from actual sending.

  • Provide (optional) validation that should reduce the chance of error responses from Apple.

  • Mock tests for when Apple does have an error response, Tests for errors from Apple #40.

  • Change ErrProcessing, etc to errors instead of strings. Error Response shouldn't need Command (8) or Status.

  • Move away from using pointers for omitempty when serializing JSON Move away from pointers for badge field? #38

  • Handle retry logic differently for cases like revoked or invalid certificates (if those can be checked before connecting, that would be great too).

  • Allow closing the client No way to close the client #25, for example if the certificate expired and a new connection is needed (though in that case it may close due to an error).

  • Reevaluate how notifications are stored and resent. Currently there is a buffer of 50 messages, which may not be enough. Rather than a maximum, another option would be to assume success after a given time period (or some combination with a much higher maximum). Also, messages aren't requeued until the next Send (on develop).

    There is also a cleanup thread running that constantly checks the oldest notification in the ‘Sent’ queue to see if it’s older than a few seconds and if so, it is assumed to have been successfully sent and is removed from the ‘Sent’ queue. - The Problem With Apples Push Notification Service

    It can take a while for the dropped connection to make its way from APNs back to your server just because of normal latency. It's possible to send over 500 notifications before a write fails because of the connection being dropped. Around 1,700 notifications writes can fail just because the pipe is full, so just retry in that case once the stream is ready for writing again. - Push Notification Throughput and Error Checking

    Maybe storing/resending notifications needs to be extracted and optional so that in-memory isn't the only option.

  • Remove determineIdentifier and require ID to be set explicitly by the caller Not sending FailedNotif if identifier not specified. #19. Or provide an identifier generator that must be called explicitly rather than passing no ID.

  • Ensure caller is aware of Error responses even if it can't be mapped to a recently sent Notification (SessionError).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant