PL5.2.0.4730 Conflict Resolution only detects externally generated conflicts

Bryan, you are making this far too complicated. Properly handled, there is no reason to “protect metadata from PhotoLab”.

To keep metadata handling simple, there’s a one path: a single canonical source of data. In this case the XMP file.

If a PhotoLab user changes any metadata, it should be reflected immediately in the XMP file. Any changes to the XMP file should be reflected immediately in PhotoLab. In this case, even with two applications changing metadata more or less at the same time (not recommended to push one’s luck, there can be OS level file control issues though sharing a txt file has long worked reliably across well-written macOS apps like BBEdit), the metadata will stay in sync. Why? Because there is a single canonical source. This is the way to avoid all the issues with sync.¹

What I could understand is a single preference to disable active handling of metadata application-wide. Your menu of write/read instructions for metadata is so complex that no one could use it reliably or the programmers maintain it. I know PhotoMechanic does have such tools but PhotoMechanic only does metadata and has been doing it for twenty plus years. Trying to add these kind of metadata manipulation tools into PhotoLab is like turning a convertible sports car into a dump truck or a bulldozer.

I would not like to see 80% of DxO’s programming team (relatively futilely) working on two-way sync for the next five years.


Notes

1. You may or may not be aware of it, but two-way sync when added to an application often requires double the programming time just for sync than the rest of the application requires. Even then reliability is spotty, particularly across OS versions. Reliable sync was the genius of Dropbox but sync got away from even Dropbox whose raison d’être is sync. Total nightmare in terms of managing an IT project. Avoid two-way sync at all costs.

1 Like