Confirmed users
1,018
edits
CloudServices/Notifications: Difference between revisions
→Issues and concerns
(→Info) |
|||
| Line 36: | Line 36: | ||
<dd>Ideally, no. While we can't make any promises when we send messages to third party services like iOS or Android, we are thinking about having the notifications server act like an IMAP service and note that you've read or deleted a given message. We're still working on that part. | <dd>Ideally, no. While we can't make any promises when we send messages to third party services like iOS or Android, we are thinking about having the notifications server act like an IMAP service and note that you've read or deleted a given message. We're still working on that part. | ||
<dt>Why not use SIP or any of the other well defined messaging protocols | <dt>Why not use SIP or any of the other well defined messaging protocols | ||
<dd>We'd love to, and it's something we're looking at as well, but there are significant problems with many of them. Mostly around things like the fact that they require a dedicated socket (which is very expensive for us to support), or require fixed IP addresses (which is problematic both for mobile devices and for most ISP users) or other reasons. To solve some of those, we're looking at doing a sliding window polling loop similar to how Sync gets updates. (Frequent checks when active, then backing off to longer delays between checks). We've seen that's a fairly good compromise between speed and cost. Now, if folks are willing to pony up for us to be able to run lots of machines with dedicated connections (or if some other organization with far deeper pockets wants to provide that service) then more power to them. | <dd>We'd love to, and it's something we're looking at as well, but there are significant problems with many of them. Mostly around things like the fact that they require a dedicated socket (which is very expensive for us to support), or require fixed IP addresses (which is problematic both for mobile devices and for most ISP users) or other reasons. To solve some of those, we're looking at doing a sliding window polling loop similar to how Sync gets updates. (Frequent checks when active, then backing off to longer delays between checks). We've seen that's a fairly good compromise between speed and cost. Now, if folks are willing to pony up for us to be able to run lots of machines with dedicated connections (or if some other organization with far deeper pockets wants to provide that service) then more power to them.<br> | ||
That said, if we're missing a golden opportunity to use some protocol we may not know about (there are a lot of them), let us know! | |||
<dt>Doesn't this mean you're the choke point for my notifications? | <dt>Doesn't this mean you're the choke point for my notifications? | ||
<dd>Yeah, unless you want to take our source code and build your own server. We'd be happy for you to do that, really. | <dd>Yeah, unless you want to take our source code and build your own server. We'd be happy for you to do that, really. | ||
<dt>When will this be ready to poke at? | <dt>When will this be ready to poke at? | ||
<dd>See the Goals section that follows | <dd>See the Goals section that follows | ||
== Goals == | == Goals == | ||