Query regarding attendee(s) inbox update.
Hi, I have been using DCS 7.0 for a while and it works great. But there is one issue I would like to have clarification. I assume server maintains inbox for all its principals. With that assumption, *Use case is as follows:* * Organizer A sends an invite to attendee B * Organizer A receives a success response from Server. *Now my question is:* Will the server update the inbox of B before sending the success response to A or will it be updated sometime after? *Reason I am asking:* In my case, A sends a client side notification to B to sync with server after receiving the success response. But some of the time, B is not getting the updates after syncing with server. If B syncs again after 5 - 10 secs, then it gets the update. Could you please provide some pointers? Best Regards, Gaurav Jain PS: Thank you for DCS.
Hello Gaurav, Glad you're enjoying CalendarServer! Short answer: recipient inboxes receive scheduling messages sometime after the sender's request is acknowledged, not inline with the request. You have noticed one of the key scalability enhancements in recent CalendarServer history: instead of synchronously delivering scheduling messages to recipients when a new or updated invitation is sent, we now create lightweight jobs (work requests) in the database to represent the actual work that is needed, typically one for each recipient, allowing the server to acknowledge the sender's request much more quickly. Shortly after the sender's request is completed, the jobs reach their start time and are processed, (perhaps by multiple / different servers in a large deployment). Various aspects of the "scheduling in the queue" implementation are configurable, however I don't recommend changing any of these settings in your situation. See conf/caldavd-stdconfig.plist: https://github.com/apple/ccs-calendarserver/blob/ff3ae19229b4ef8d72173c5eae6... The exact amount of time it takes for a given recipient's inbox to update after an invitation was sent depends on various factors (configuration, number of attendees, server performance / load), so the best way to know when a specific inbox has a new message is to let the server tell you. CalendarServer offers two different notification systems: Apple Push Notification Service, and AMP (Asynchronous Message Passing, a Twisted framework). APNS is only an option for Apple platforms, but AMP can be integrated into other projects pretty easily - check out the docs: http://twistedmatrix.com/documents/current/api/twisted.protocols.amp.html You would need to write an implementation for these three commands: https://github.com/apple/ccs-calendarserver/blob/e8c1adf17f4fa661926d70d2ddf... ... and since your goal appears to be to tell *another* system to refresh because *IT* has received a new message, I might recommend implementing the AMP client on that system, if possible, to minimize the layers of indirection. Cheers, -dre
On Sep 12, 2016, at 1:35 PM, Gaurav Jain <monkeyfdude@gmail.com> wrote:
Hi,
I have been using DCS 7.0 for a while and it works great. But there is one issue I would like to have clarification.
I assume server maintains inbox for all its principals. With that assumption,
Use case is as follows:
* Organizer A sends an invite to attendee B * Organizer A receives a success response from Server.
Now my question is:
Will the server update the inbox of B before sending the success response to A or will it be updated sometime after?
Reason I am asking:
In my case, A sends a client side notification to B to sync with server after receiving the success response.
But some of the time, B is not getting the updates after syncing with server.
If B syncs again after 5 - 10 secs, then it gets the update.
Could you please provide some pointers?
Best Regards, Gaurav Jain
PS: Thank you for DCS.
_______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-users
Thank you for the response. I will look into AMP. *Can you please point me to APNS docs/examples as well?* Best Regards, Gaurav Jain On Mon, Sep 12, 2016 at 5:14 PM, Andre LaBranche <dre@apple.com> wrote:
Hello Gaurav,
Glad you're enjoying CalendarServer!
Short answer: recipient inboxes receive scheduling messages sometime after the sender's request is acknowledged, not inline with the request.
You have noticed one of the key scalability enhancements in recent CalendarServer history: instead of synchronously delivering scheduling messages to recipients when a new or updated invitation is sent, we now create lightweight jobs (work requests) in the database to represent the actual work that is needed, typically one for each recipient, allowing the server to acknowledge the sender's request much more quickly. Shortly after the sender's request is completed, the jobs reach their start time and are processed, (perhaps by multiple / different servers in a large deployment).
Various aspects of the "scheduling in the queue" implementation are configurable, however I don't recommend changing any of these settings in your situation. See conf/caldavd-stdconfig.plist: https://github.com/apple/ccs-calendarserver/blob/ ff3ae19229b4ef8d72173c5eae67636f3adec198/conf/caldavd- stdconfig.plist#L1569
The exact amount of time it takes for a given recipient's inbox to update after an invitation was sent depends on various factors (configuration, number of attendees, server performance / load), so the best way to know when a specific inbox has a new message is to let the server tell you. CalendarServer offers two different notification systems: Apple Push Notification Service, and AMP (Asynchronous Message Passing, a Twisted framework). APNS is only an option for Apple platforms, but AMP can be integrated into other projects pretty easily - check out the docs:
http://twistedmatrix.com/documents/current/api/twisted.protocols.amp.html
You would need to write an implementation for these three commands:
https://github.com/apple/ccs-calendarserver/blob/ e8c1adf17f4fa661926d70d2ddf8758d00aae06c/calendarserver/ push/amppush.py#L35-L53
... and since your goal appears to be to tell *another* system to refresh because *IT* has received a new message, I might recommend implementing the AMP client on that system, if possible, to minimize the layers of indirection.
Cheers, -dre
On Sep 12, 2016, at 1:35 PM, Gaurav Jain <monkeyfdude@gmail.com> wrote:
Hi,
I have been using DCS 7.0 for a while and it works great. But there is one issue I would like to have clarification.
I assume server maintains inbox for all its principals. With that assumption,
*Use case is as follows:*
* Organizer A sends an invite to attendee B * Organizer A receives a success response from Server.
*Now my question is:*
Will the server update the inbox of B before sending the success response to A or will it be updated sometime after?
*Reason I am asking:*
In my case, A sends a client side notification to B to sync with server after receiving the success response.
But some of the time, B is not getting the updates after syncing with server.
If B syncs again after 5 - 10 secs, then it gets the update.
Could you please provide some pointers?
Best Regards, Gaurav Jain
PS: Thank you for DCS.
_______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-users
Apple Push Notification Service (APNS) is documented on the Apple Developer site: https://developer.apple.com/library/ios/documentation/NetworkingInternet/Con... <https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html#//apple_ref/doc/uid/TP40008194-CH100-SW9>
On Sep 12, 2016, at 7:57 PM, Gaurav Jain <monkeyfdude@gmail.com> wrote:
Thank you for the response. I will look into AMP.
Can you please point me to APNS docs/examples as well?
Best Regards, Gaurav Jain
On Mon, Sep 12, 2016 at 5:14 PM, Andre LaBranche <dre@apple.com <mailto:dre@apple.com>> wrote: Hello Gaurav,
Glad you're enjoying CalendarServer!
Short answer: recipient inboxes receive scheduling messages sometime after the sender's request is acknowledged, not inline with the request.
You have noticed one of the key scalability enhancements in recent CalendarServer history: instead of synchronously delivering scheduling messages to recipients when a new or updated invitation is sent, we now create lightweight jobs (work requests) in the database to represent the actual work that is needed, typically one for each recipient, allowing the server to acknowledge the sender's request much more quickly. Shortly after the sender's request is completed, the jobs reach their start time and are processed, (perhaps by multiple / different servers in a large deployment).
Various aspects of the "scheduling in the queue" implementation are configurable, however I don't recommend changing any of these settings in your situation. See conf/caldavd-stdconfig.plist: https://github.com/apple/ccs-calendarserver/blob/ff3ae19229b4ef8d72173c5eae6... <https://github.com/apple/ccs-calendarserver/blob/ff3ae19229b4ef8d72173c5eae67636f3adec198/conf/caldavd-stdconfig.plist#L1569>
The exact amount of time it takes for a given recipient's inbox to update after an invitation was sent depends on various factors (configuration, number of attendees, server performance / load), so the best way to know when a specific inbox has a new message is to let the server tell you. CalendarServer offers two different notification systems: Apple Push Notification Service, and AMP (Asynchronous Message Passing, a Twisted framework). APNS is only an option for Apple platforms, but AMP can be integrated into other projects pretty easily - check out the docs:
http://twistedmatrix.com/documents/current/api/twisted.protocols.amp.html <http://twistedmatrix.com/documents/current/api/twisted.protocols.amp.html>
You would need to write an implementation for these three commands:
https://github.com/apple/ccs-calendarserver/blob/e8c1adf17f4fa661926d70d2ddf... <https://github.com/apple/ccs-calendarserver/blob/e8c1adf17f4fa661926d70d2ddf8758d00aae06c/calendarserver/push/amppush.py#L35-L53>
... and since your goal appears to be to tell *another* system to refresh because *IT* has received a new message, I might recommend implementing the AMP client on that system, if possible, to minimize the layers of indirection.
Cheers, -dre
On Sep 12, 2016, at 1:35 PM, Gaurav Jain <monkeyfdude@gmail.com <mailto:monkeyfdude@gmail.com>> wrote:
Hi,
I have been using DCS 7.0 for a while and it works great. But there is one issue I would like to have clarification.
I assume server maintains inbox for all its principals. With that assumption,
Use case is as follows:
* Organizer A sends an invite to attendee B * Organizer A receives a success response from Server.
Now my question is:
Will the server update the inbox of B before sending the success response to A or will it be updated sometime after?
Reason I am asking:
In my case, A sends a client side notification to B to sync with server after receiving the success response.
But some of the time, B is not getting the updates after syncing with server.
If B syncs again after 5 - 10 secs, then it gets the update.
Could you please provide some pointers?
Best Regards, Gaurav Jain
PS: Thank you for DCS.
_______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org <mailto:calendarserver-users@lists.macosforge.org> https://lists.macosforge.org/mailman/listinfo/calendarserver-users <https://lists.macosforge.org/mailman/listinfo/calendarserver-users>
_______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-users
On Sep 12, 2016, at 7:57 PM, Gaurav Jain <monkeyfdude@gmail.com> wrote:
Can you please point me to APNS docs/examples as well?
Hi, Unfortunately APNS with CalendarServer is only supported when using Server.app, and only with Apple clients. This is because the APNS servers will only send pushes to Apple clients (via platform security controls). Also note that the Calendar.app client will only accept pushes associated with an APNS cert that contains a topicID in a (restricted) Apple namespace that is not available to third parties that obtain APNS server certs via the certificate portal website. Server.app is entitled to request certs in this restricted namespace, authenticated with iCloud credentials. Getting APNS to work for Apple clients and servers is simple: just turn it on in the Server.app GUI, and clients should notice and switch to APNS instead of polling. -dte
Hi Andre, I am trying to get AMP push working.* Please pardon my ignorance on this.* Is there a sample implementation/design for AMP push SubscribeToID / UnsubscribeFromID / NotificationForID ? I am not sure about the design and how to move forward on this. * How does SubscribeToID / UnsubscribeFromID / NotificationForID work? * How would their implementation/design look like ? Please provide pointers. http://twistedmatrix.com/documents/current/api/twisted.protocols.amp.html https://github.com/apple/ccs-calendarserver/blob/ e8c1adf17f4fa661926d70d2ddf8758d00aae06c/calendarserver/ push/amppush.py#L35-L53 On Tue, Sep 13, 2016 at 9:33 AM, Andre LaBranche <dre@apple.com> wrote:
On Sep 12, 2016, at 7:57 PM, Gaurav Jain <monkeyfdude@gmail.com> wrote:
Can you please point me to APNS docs/examples as well?
Hi,
Unfortunately APNS with CalendarServer is only supported when using Server.app, and only with Apple clients. This is because the APNS servers will only send pushes to Apple clients (via platform security controls). Also note that the Calendar.app client will only accept pushes associated with an APNS cert that contains a topicID in a (restricted) Apple namespace that is not available to third parties that obtain APNS server certs via the certificate portal website. Server.app is entitled to request certs in this restricted namespace, authenticated with iCloud credentials.
Getting APNS to work for Apple clients and servers is simple: just turn it on in the Server.app GUI, and clients should notice and switch to APNS instead of polling.
-dte
participants (3)
-
Andre LaBranche
-
Gaurav Jain
-
Morgen Sagen