Here's the current breakdown of child, extension, and delegation relationships and their properties, as I see them:
| Relationship | Can be directly owned | sub pulls in super | super pulls in sub if open | closing super abandons sub |
|---|---|---|---|---|
| child | ✓ | ✓ | ✗ | ✗ |
| extension | ✗ | ✗ | ✓ | ✓ |
| delegation | ✓ | ✓ | ✗ | ✓ |
What if we leave child cases unchanged, but merge the concepts of extensions and delegations:
| Relationship | Can be directly owned | sub pulls in super | super pulls in sub if open | closing super abandons sub |
|---|---|---|---|---|
| child | ✓ | ✓ | ✗ | ✗ |
| extension | ✓ | ✓ | ✓ | ✓ |
The current conception of extension cases feels quite awkward to me, as does the fact that it doesn't solve one of the two main use-cases it was conceived for. Perhaps the most awkward part about extension cases is the idea that they don't have any ownership of their own, so assigning them to someone else does nothing.
That seems like a whole set of potential use-cases that we're abandoning. If we allow them to be owned, and allow them to pull in their host, you can still easily simulate the other behavior (can't be owned, doesn't pull in host) by setting the owner_id to ''. In fact, that will likely be the default.
Delegation cases, on the other hand, don't seem to be gaining much by disappearing from the parent's owners' phones. In fact, you may very well want to track progress on your delegation cases, and it's easy to filter out the ones you don't own.
If you adjust extensions and delegations in the way I implied, then they end up being the same thing, at least if you agree with the table.
An extension index would then be very much like a child index, except that in addition to pulling its parent in onto phones where it's live, it also:
- stays on the phones where its parent is live
- gets pulled from all phones when the parent is closed
In other words, it's tied much more tightly to the parent's lifecycle and always accessible whenever the parent is, while still maintaining the ability (like a child case) to go out in the world and live its own life.
I'll introduce two concepts here, available, and live. Available applies globally, where as live only has meaning in the in the context of a given user.
Conceptually, available means not precluded from being on a phone due to a parent being closed (a property of extesion cases).
A case is available if
- it is open and not an extension case
- it is open and is the extension of an available case.
Conceptually, live means a case that should be on the user's phone.
In the description below owned means directly owned by the user or owned by a group that the user belongs to.
A case is live if any of the following are true:
- it is owned and available
- it has a live child
- it has a live extension
- it is the exension of a live case
The mobile phone and HQ may use the same algorithm or different algorithms to arrive at the set of cases that are live as long as they end up with the same result.
It's one thing to outline a simple recursive definition as I have above, and another to have an efficient implementation of it. I'll try to outline one here.
This algorithm has the following phases:
- Mark relevant cases
- Mark available cases
- Mark live cases
In order to make the algorithm computationally accessible, we first cast a wide net to include any case that could possibly factor into the liveness calculation, and then limit all future calculations to cases in that set. (This means, for example, we don't have to decide whether every single case in a project is available just to find the set of cases live for a user.) To do that, I'll have to add one more "declaritive style" definition:
A case is relevant if any of the following are true:
- it is open and owned
- it has a relevant child
- it has a relevant extension
- it is the extension of a relevant case
Now the algorithm is as follows:
- Mark all open cases owned by the user relevant
- Traversing all outgoing child and extension indexes, as well as all incoming extension indexes, mark all touched cases relevant.
- Mark all relevant cases that are open and have no outgoing extension indexes as available
- Traversing all incoming extension indexes, mark all touched cases available
- Mark all relevant, owned, available cases as live
- Traversing all outgoing child and extension indexes, as well as incoming extension indexes, mark all touched cases as live.
Hey,
Looks good so far! I'm getting much clearer here.
I also made a pass at the algorithm, which I made before your new definitions of relevant / available. Adding it here for discussion purposes -- first time I've done something like this, so probably needs a bunch of tweaking.
Definitions
"Extension" -> owner_id = None
"Delegate" -> owner_id set
Fetch pertinent cases
start with all cases with my owner id (regular, child, delegate)
for all of these cases, recursively pull:
Mark:
Traversal
All live cases should be synced.