I think it's worth separating this into at least two different problems. Sync — a shared whiteboard object store — is currently (ab)used to achieve two and a half different things:
1. Real shared data like passwords. All clients read and write the same records. 2. One-way data like open tabs. One client writes their record, and all other clients read it. 3. Kinda-one way command channel data via the clients record: all clients sometimes write any record, but one client owns it. Sending a tab is a particular kind of command. Implementing one-shot one-recipient commands via the Sync clients engine is really, really horrible. The client code is complicated, it doesn't scale, and timeliness is only one of its problems. Making (3) more timely via push notifications is feasible, because by definition only one client needs to be pinged. As a Send Tab user, I would find it valuable. But it doesn't get us any closer to a good command channel, and it's a special case solution that doesn't address (2) or (1). So we should be clear that this is continuing to invest in something that we really want to replace. Making (2) more timely is very feasible and potentially valuable, because there is less chance of write contention — only one client writes each record. But see the extensive cost worries in Bug 1222594 <https://bugzilla.mozilla.org/show_bug.cgi?id=1222594>: the design of the Sync tabs format is deeply flawed, and adding push to the mix only makes those flaws more apparent. Making (1) — the other collections — more timely is potentially very valuable, but simply pinging clients is going to result in race problems, because many of Sync's bugs are provoked when more than one client syncs at a time. You might be able to work around this by being very careful to define what each push notification means, but pretty soon you'll be knee-deep in distributed voting protocols… All this means you should be very clear about which sets of problems you're planning to solve, and try to solve them very, very carefully. There are lifecycle concepts in your description ("post-sync") that aren't known by the server. Honestly, the Sync server is pretty blind, so using it as a clearing house for triggering pushes is fine, but having it try to divine the right time to send notifications seems like the wrong direction. Personally I'd like to see clients be aware of devices, and able to send push notifications themselves (directly or not). When sending a tab they would *directly* push the command, not involving Sync at all, unless the other device wasn't push-aware. This bootstraps us out of the existing Sync object formats, so we could build a strictly better system. That client-driven solution also generalizes itself to addressing (2) ("hey laptop, upload your open tabs!" "hey phone, I uploaded my tabs!") and is no worse at solving (1) than any other approach. On Mon, May 9, 2016 at 4:29 PM, Edouard Oger <[email protected]> wrote: > Hello everyone, > > We want to use the new Push API to improve the general latency of Sync > between operations. > Let's consider for example the case of sending a tab to another synced > device : Device A writes in the /clients collection an opentab command > and pushes its changes to the sync server. On its next sync, Device B > will pick up the new tabs in the /clients collection and open them. > We want to keep this behavior because it works and we would like to > avoid having push servers as a mandatory dependency. > The plan is to send a Push notification to Device B to tell it to sync > its /clients collection immediately because "something changed". > In this case, the push technology only accelerates things, but does not > change the underlying protocol. > > Which brings us to the architecture problem: > The Firefox Accounts servers already have a list of devices and their > associated pushCallbackUrls, but this server is not hit when we sync > things up and it would be semantically bizarre to send a request to this > server after syncing something. > > We discussed this with ckarlof and we ended up thinking that the sync > storage servers should send the notifications themselves: Post-sync, > retrieve the device list from the FxA server, maybe cache it, try to > figure out the correspondence between its own device list and the FxA > device list (is this a solved problem?) and send the push notifications. > > We feel like keeping a single source of truth for the pushCallbackUrls > on the FxA servers is important. > > What do you think of this solution? I would appreciate feedback on this. > > Thanks, > Edouard > > _______________________________________________ > Sync-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/sync-dev > >
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
