kumpelblase2 / focus Goto Github PK

Initially, I just ignored the REFERENCE elements as I thought they didn't provide any meaningful information. However, I realized that they do contain a copy of the "current" state of the element and thus could be used to make sure that the current state matches the state that it had when the reference was used. For example, if I assign a tag/context to task, it would include a reference element which I could inspect and compare to my current state of that task to make sure that they match.

Upon further investigation, this does not seem to be true. I initially investigated a problem where the values were ever so slightly different (e.g. null vs false, where false would be the default) but then I noticed that the reference had older information compared to the state of the context. In other words, the state of that context up until the changeset the reference was in had newer data compared to the reference data which was evident by the modified data time. My test setup was as follows:

1. create a new tag
2. create two new tasks under it
3. re-order the two tasks

I expected omnifocus to create some changesets with the first changeset containing a changeset element to create the new context. But when inspected the first changeset looks like this:

<omnifocus>
    <task id="liQWUzkwNwI">
        <added>2020-09-18T07:49:16.713Z</added>
        <rank>2145669890</rank>
        <context idref="kW9To0NYLP4"/>
    </task>
    <task-to-tag id="liQWUzkwNwI.kW9To0NYLP4">
        <added order="1">2020-09-18T07:49:16.713Z</added>
        <task idref="liQWUzkwNwI"/>
        <context idref="kW9To0NYLP4"/>
        <rank-in-task>0001</rank-in-task>
        <rank-in-tag/>
    </task-to-tag>
    <context id="kW9To0NYLP4" op="reference">
        <reference-snapshot>
            <added>2020-09-18T07:48:51.720Z</added>
            <modified>2020-09-18T07:48:53.892Z</modified>
            <name>test</name>
            <rank>2146435072</rank>
            <prohibits-next-action>false</prohibits-next-action>
            <tasks-user-ordered>false</tasks-user-ordered>
        </reference-snapshot>
    </context>
</omnifocus>

(Some parts removed for clarity)

The context already appears as a reference as if it already exists! What's even more interesting (worrisome?) is that the original changeset has been retroactively altered to already contain the newly created tag:

<!-- ... -->
<context id="kW9To0NYLP4">
    <added>2020-09-18T07:48:51.720Z</added>
    <name>test</name>
    <rank>2146435072</rank>
    <prohibits-next-action>false</prohibits-next-action>
    <tasks-user-ordered>true</tasks-user-ordered>
    <modified>2020-09-18T07:49:23.154Z</modified>
</context>
<!-- ... -->

Notice that the modified time is after the time inside the previous reference! Additionally, the changes that later impacted it, specifically tasks-user-ordered being true, are also already present here. This seems to be weird as I would expect that the original changeset will only ever get updated by merging certain changesets together and not to simply already include some data. I don't understand why this is done instead of just simply adding the context/tag in the changeset. It feels completely wrong to change the base if the idea is to have individual "patches" applied on top for every change.

It could also be that this snapshot is still meant for when clients want to know what the reference looked like at the time of use so that if they have a locally changed copy they can compare and decide what to do. However, I still feel like I'm missing a piece of the puzzle here.

I think for now the course of action looks like this:

1. revert to the previous behavior where the reference was just ignored
2. provide functionality for "updating" the store by loading new changesets
3. while updating check the references for equality