3 ms·

I often think we should have a separation of concern between storing/syncing data and application code. That syncing app files should be an OS level feature, w

I often think we should have a separation of concern between storing/syncing data and application code. That syncing app files should be an OS level feature, with many different available data stores, and sync well across different platforms.

xmprt 3y ago
Conflict resolution logic is typically application specific so it would be hard to get something like this working in practice.
- simultsop 3y ago
  If it is a solo user, latest data would be enough to sync. Asuming the blog post tackles personal need app, single user.
  - LtWorf 3y ago
    What if you were offline for a while?
- vbezhenar 3y ago
  Do not allow offline mode and make fsync block until server acknowledges write.
  - _yb2s 3y ago
    Depending on the nature of the data, you can design the app to have a write only journal with independent entries, that are always possible to merge in a consistent way at a later time. This obviously works better for very simple things like a "play history" and not for complex things like collaborative document writing.
- TheCoreh 3y ago
  iCloud already supports this, and from what I gather it works decently well: https://developer.apple.com/documentation/uikit/uidocumentstate/uidocumentstateinconflict https://developer.apple.com/documentation/uikit/uidocumentst... https://developer.apple.com/library/archive/technotes/tn2336/_index.html https://developer.apple.com/library/archive/technotes/tn2336... Essentially there's an OS mechanism for getting the different versions of the file, your app can detect conflicts and choose how to resolve them, including by displaying arbitrary UI to the user. IIRC This UI can even be integrated with the file open dialog. As a last resort fallback if the app doesn't resolve it Finder/Files will let you keep either version or both (as separate files)
  - jeremyjh 3y ago
    > your app can detect conflicts and choose how to resolve Like GP said - app specific. If I have two different versions of a SQLite database, that started from a common revision but were both updated independently, and want the updates that were applied in each of them to be preserved - there is quite a lot of work left to do after Apple throws their hands up.
    - saurik 3y ago
      You wouldn't (and don't) use this kind of mechanism at the file-level on an entire SQLite database: just because someone suggests something be an OS feature doesn't mean that existing software would work without changes.
      - jeremyjh 3y ago
        > You wouldn't (and don't) use this kind of mechanism at the file-level on an entire SQLite database: But the OFA is about databases, and this thread is about syncing databases. So you agree with me: the Apple feature is worthless for this use case. GGP was right that its a lot of work to build sync with conflict resolution into an application, and its application specifc.
jasonjayr 3y ago
It should be OS-level, but in 2024 NO vendor (Apple, Microsoft, Google) is going to make a new open protocol for cross-platform syncing, w/o binding it tightly to their authentication platform/device security system/etc.

xmprt 3y ago

Conflict resolution logic is typically application specific so it would be hard to get something like this working in practice.

simultsop 3y ago
If it is a solo user, latest data would be enough to sync. Asuming the blog post tackles personal need app, single user.
- LtWorf 3y ago
  What if you were offline for a while?
vbezhenar 3y ago
Do not allow offline mode and make fsync block until server acknowledges write.
- _yb2s 3y ago
  Depending on the nature of the data, you can design the app to have a write only journal with independent entries, that are always possible to merge in a consistent way at a later time. This obviously works better for very simple things like a "play history" and not for complex things like collaborative document writing.
TheCoreh 3y ago
iCloud already supports this, and from what I gather it works decently well: https://developer.apple.com/documentation/uikit/uidocumentstate/uidocumentstateinconflict https://developer.apple.com/documentation/uikit/uidocumentst... https://developer.apple.com/library/archive/technotes/tn2336/_index.html https://developer.apple.com/library/archive/technotes/tn2336... Essentially there's an OS mechanism for getting the different versions of the file, your app can detect conflicts and choose how to resolve them, including by displaying arbitrary UI to the user. IIRC This UI can even be integrated with the file open dialog. As a last resort fallback if the app doesn't resolve it Finder/Files will let you keep either version or both (as separate files)
- jeremyjh 3y ago
  > your app can detect conflicts and choose how to resolve Like GP said - app specific. If I have two different versions of a SQLite database, that started from a common revision but were both updated independently, and want the updates that were applied in each of them to be preserved - there is quite a lot of work left to do after Apple throws their hands up.
  - saurik 3y ago
    You wouldn't (and don't) use this kind of mechanism at the file-level on an entire SQLite database: just because someone suggests something be an OS feature doesn't mean that existing software would work without changes.
    - jeremyjh 3y ago
      > You wouldn't (and don't) use this kind of mechanism at the file-level on an entire SQLite database: But the OFA is about databases, and this thread is about syncing databases. So you agree with me: the Apple feature is worthless for this use case. GGP was right that its a lot of work to build sync with conflict resolution into an application, and its application specifc.

jasonjayr 3y ago

It should be OS-level, but in 2024 NO vendor (Apple, Microsoft, Google) is going to make a new open protocol for cross-platform syncing, w/o binding it tightly to their authentication platform/device security system/etc.