Implement Sync Device API #6

New Issue

Jef Roosens · 2025-03-04T19:31:21Z

Jef Roosens commented

2025-03-04 19:31:21 +00:00

The Sync Device API configures which devices are synchronised. Devices are part of a sync group, and all changes to subscriptions on a device are also performed on all other devices in the same sync group. If two devices are already in separate sync groups and they're marked as "synchronize", their sync groups should be merged inton one big group.

Subscriptions should still be stored per device instead of a per sync group as different devices can have different time_changed values for subscriptions.

Todo

Design abstraction for sync status
Implement abstraction in Sqlite repository
- sync status functions
- update subscription functions to change all devices in sync group
Implement routes using abstraction

The Sync Device API configures which devices are synchronised. Devices are part of a sync group, and all changes to subscriptions on a device are also performed on all other devices in the same sync group. If two devices are already in separate sync groups and they're marked as "synchronize", their sync groups should be merged inton one big group. Subscriptions should still be stored per device instead of a per sync group as different devices can have different `time_changed` values for subscriptions. ## Todo - [x] Design abstraction for sync status - [ ] Implement abstraction in Sqlite repository - sync status functions - update subscription functions to change all devices in sync group - [ ] Implement routes using abstraction

Jef Roosens added the

enhancement

label 2025-03-04 19:31:21 +00:00

Jef Roosens self-assigned this 2025-03-04 19:31:21 +00:00

Jef Roosens commented

2025-03-04 20:28:33 +00:00

Poster

My initial assumption seemed to be incorrect. The source code of the original GPodder.net server seems to imply the API allows defining which devices sync with which other devices. It's not simply a boolean flag.

My initial assumption seemed to be incorrect. The [source code](https://github.com/gpodder/mygpo/blob/master/mygpo/api/advanced/sync.py) of the original GPodder.net server seems to imply the API allows defining which devices sync with which other devices. It's not simply a boolean flag.

Jef Roosens commented

2025-03-04 21:50:14 +00:00

Poster

The way I understand it (by reading the Gpodder source code):

Each device can be part of a "sync group". Devices in the same sync group are synchronized, which for the Gpodder.net server means the backend performs some sort of sync between the devices. That probably doesn't matter much for this server.

{
  "synchronize": [
       ["notebook", "netbook"]
     ],
  "stop-synchronize": ["pc-work"]
}

This API request means "synchronize devices notebook and netbook and stop synchronizing the device pc-work". With "synchronize devices", this means to add both devices to the same sync group. If both devices are already in a sync group, the sync groups are merged into a single group. The "stop-synchronize" devices should simply be removed from their sync group.

{
  "synchronized": [
       ["notebook", "netbook", "n900"]
   ],
  "not-synchronized": [
       "test-pc", "pc-work", "pc-home"
   ]
}

The above response is then obtained by grouping the devices by their sync group.

The way I understand it (by reading the Gpodder source code): Each device can be part of a "sync group". Devices in the same sync group are synchronized, which for the Gpodder.net server means the backend performs some sort of sync between the devices. That probably doesn't matter much for this server. ```json { "synchronize": [ ["notebook", "netbook"] ], "stop-synchronize": ["pc-work"] } ``` This API request means "synchronize devices `notebook` and `netbook` and stop synchronizing the device `pc-work`". With "synchronize devices", this means to add both devices to the same sync group. If both devices are already in a sync group, the sync groups are merged into a single group. The "stop-synchronize" devices should simply be removed from their sync group. ```json { "synchronized": [ ["notebook", "netbook", "n900"] ], "not-synchronized": [ "test-pc", "pc-work", "pc-home" ] } ``` The above response is then obtained by grouping the devices by their sync group.

Jef Roosens commented

2025-03-16 09:51:39 +00:00

Poster

The sync API seems to be crucial for clients to properly sync with each other.

The sync-device API routes allow specifying which devices should be part of the same sync group. When this happens, a full sync of the devices should be performed server-side. Any time a subscription is added or removed, this change should be applied to all devices in the same sync group as the target device.

Considering it's more common (I'd expect) to keep devices in the same sync group, it might be better to switch our database model to linking subscriptions to sync groups instead of devices. Subscriptions would be added to and removed from the device's sync group, and any queries would be performed on the sync group instead. This would make joining and splitting sync groups a bit harder though.

The sync API seems to be crucial for clients to properly sync with each other. The `sync-device` API routes allow specifying which devices should be part of the same sync group. When this happens, a full sync of the devices should be performed server-side. Any time a subscription is added or removed, this change should be applied to all devices in the same sync group as the target device. Considering it's more common (I'd expect) to keep devices in the same sync group, it might be better to switch our database model to linking subscriptions to sync groups instead of devices. Subscriptions would be added to and removed from the device's sync group, and any queries would be performed on the sync group instead. This would make joining and splitting sync groups a bit harder though.

Jef Roosens added this to the 0.1.0 milestone 2025-03-16 19:37:23 +00:00

Jef Roosens closed this issue

2025-03-20 18:27:30 +00:00

Sign in to join this conversation.