2022/07/21/FutilityCloud process design

Codeblog 2023/06/04 config classes 2023/05/01 DataPorts redesign 2022/07/21 FutilityCloud process design 2022/08/14 Windows joke I wrote in the late 1900s (on TootCat) 2022/07/21 render-dispatch rubberduckery 2022/07/20 comments on The Home Computer Generation 2022/07/18 layout-event rubberducking 2022/06/24 event-object as output container: the consequences 2022/06/23 event-object as output container: the revision 2022/05/30 more data-class rubberducking 2022/05/20 rubberducking about data classes 2022/01/15 standard CV data format 2021/12/17 The Great Data-Class Restacking 2021/11/25 PHP documentation gripe 2021/11/24 things you can't do in PHP 2021/11/23 PortBank refactoring part 2 2021/11/22 PortBank refactoring part 1 2021/11/08 data objects refactoring 2021/11/05 notes for event-system burndown 2021/07/31 a code mystery 2021/05/31 new PHP wishlist item: first keyword 2021/05/28 a kluge using abstract methods 2021/03/21 PHP wishlist 2020/12/04 (notes) 2020/10/30 (notes) 2020/10/29 (notes) 2020/10/28 (notes) 2020/10/27 (notes: Dovecot on cloud5) 2020/08/29 MediaWiki SpecialPages 2020/08/25 The Plex API 2020/06/12 Ferreteria: thoughts on the Wikcess/flex-data system 2020/04/23 Ferreteria: quick notes on a design issue 2020/04/22 Ferreteria: some thoughts on apps vs. frameworks 2020/02/10 job application (yes, I actually sent this in)

Getting back to work on the Human Futillities Nexcloud-client replacement functionality...

Thinking this over last night, it is a bit of a complex problem -- or at least there are issues which may come up that require complex solutions.

I think it can be divided up into layers of complexity, where each layer deals with what it can resolve and then defers the stuff needing more analysis for the next layer to handle.

Layers

From simpler to more complex:

Layer 1 just does a straight 1:1 folder-tree comparison. Where the same file exists in the same folder, it checks to see if they are identical; if they are not, it keeps the newer one (and archives the older one). Where they are identical but with different timestamps, it keeps the older timestamp.

Where a file is missing from one, we have to look deeper -- is it missing because it's new, or because it was recently (intentionally) deleted, or because it's been moved? You can't get a timestamp for a file that isn't there. So we defer those to Layer 2.

Layer 2 looks at a recent tree-index (FTI) to see if the missing file has just been moved somewhere. If it has, though, how do we decide which repo has the newer information? We could look at the timestamp on each folder, but if both folders contain more than one change, that's inconclusive. In the edge-case where there's at least one folder that has no other changes in it and existed both before and after, we could let that timestamp determine which is more recent. I don't know if this will happen very often.

For more certainty, though, we will need...

Layer 3 attempts to keep a log of changes as they occur on each end, hopefully through using a filesystem hook to receive notifications when files are changed or moved. Where the log is discontinuous, we'll have to defer back to Layer 2 methods. For timespans where the log is available on both ends, though, we can see what the actual sequence of events was, and make sure it's replicated on both ends. (There will be cases where the two sides contradict each other, but those should be rare... we'll treat that as another possible layer.

Deferral: Ideally, we'll have a decent UI for manually resolving ambiguity at any layer. It should also be possible to disable automatic resolution, where it exists, and relatively easy to modify the heuristics for automatic resolution.

Overall

This lets me build the functionality incrementally. I can start with the simplest layer, have it write a list of files with issues needing next-layer attention, and temporarily use manual resolution to deal with those (they should be only a small percentage of the total, I think -- but even if not, this lets me deal with the backlog of new files on each end) -- and then eventually automate that layer and move on to the next.