Hello,
I'm unable to answer all your questions.
As I know, James doesn't have a backend repository to store data similar
to your use case.
At Linagora, we encountered a similar situation when implementing
Firebase. Consequently, we opted to develop a dedicated repository for
storage.
If you want to reference the code, you can visit
https://github.com/linagora/tmail-backend/tree/master/tmail-backend/jmap/extensions/src/main/java/com/linagora/tmail/james/jmap/firebase
Hope that help you a bit
On 07/12/2023 15:36, Andre Borie wrote:
Hello and hope everyone is well. I would like your help as to how best to
implement Apple Push notification support.
For a bit of context, Apple iOS does not use IMAP IDLE - instead it uses a proprietary IMAP command
"XAPPLEPUSHSERVICE" combined with Apple's hosted push notifications service
"APNS".
When an iOS device connects to a supported server advertising the
"XAPPLEPUSHSERVICE" capability, the device issues an XAPPLEPUSHSERVICE IMAP
command with the following contents:
* account-id: opaque blob that must be quoted in subsequent notifications
* subtopic: APNS subtopic, must be used when sending subsequent notifications
* device token: the APNS identifier of the device, must be used to send
subsequent notifications
* list of mailboxes: list of IMAP mailbox names (from the perspective of the
iOS IMAP client) to monitor and send notifications upon changes
The IMAP server replies with an APNS topic (mostly static value, derived from the
certificate it uses to talk to APNS). Then, when changes occur in the aforementioned
mailboxes, the server must send a notification via APNS (a persistent connection to an
Apple server authenticated by a client certificate) towards the aforementioned device
token & subtopic, quoting the account ID & client-facing mailbox name. The
notification is relayed by Apple to the target device which prompts it to wake up and
fetch the new messages via IMAP.
This would require us to:
* store (device_token, account_id, subtopic, client-specific IMAP mailbox name)
tuples against a given Mailbox
* react to mailbox events and enqueue notifications for each of the above tuples
* maintain a persistent connection to APNS to dequeue & forward those
notifications to
First question would be whether you'd be interested in including this in James
core, or if this should remain a separate extension? If included in core, it
would require James to be able to accept another keystore (with the APNS
certificate, created by a helper program) and be able to reload it on the fly
to enable zero-downtime certificate rotations.
If interested in upstreaming, would you be able to outline a high-level
overview of what the code should look like, especially where to put the APNS
client?
On the other hand, if it's better to keep it as an extension, I want to know
whether James has a way for extensions to attach arbitrary data to a mailbox
(so I can store the device tokens) without changing the storage backends? Also,
where to put the long-lived APNS client? Does James have an existing extension
pattern that accounts for long-lived services like this?
For reference, I currently have a proof of concept extension at
https://github.com/Rjevski/apache-james-xapsd-registration-extension which is
an IMAP extension (implementing the custom command) and mailbox listener -
however, the storage of mailbox to device token mappings and APNS communication
is delegated to an external service called over HTTP.
Regards.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
