You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is it in the scope of the spec to support a scenario where a notification receiver is temporarily offline, yet the notification sender stores it (with at ttl) and streams then once the notification receiver reestablishes connection?
The text was updated successfully, but these errors were encountered:
I would certainly hope that the SNP (Solid Notification Protocol) would have robustness similar to SMTP or NNTP. I will also note that SMTP and NNTP routing interruptions of years have occurred, with messages continuing on their way upon restoration of communication (i.e., when the relevant machine(s) were rebooted and/or hubs/switches/routers reconnected), and that even this delayed delivery was appreciated by the recipients/readers.
Is it in the scope of the spec to support a scenario where a notification receiver is temporarily offline, yet the notification sender stores it (with at ttl) and streams then once the notification receiver reestablishes connection?
The text was updated successfully, but these errors were encountered: