Mine / Not-Mine

When a user subscribes to a shared collection, they will be given the option to either add the imported items into their "My items" collection, or to keep those items out of "My items". So how do we implement this with the new collection classes?

First, let's look at how we currently determine what's in "My items" (aka the "All" collection). This figure is an (ugly) rendition of the hierarchy of 'sources' that feed into the All collection:

(This hierarchy is now rendered in the repository servlet whenever you view a collection item. If somebody feels like making this more readable, please feel free to improve it.

Mine/Not-Mine could be thought of either as the property of an item, or as the property of a collection.

Basing Mine/Not-Mine on collections

If it's the property of a collection, then we could change the All sources tree to look like:

[Choice 1, "Not-Mine UnionCollection^?"] What I've done (as a test in my local tree) is created a UnionCollection^? called 'Not Mine' whose sources would be every collection whose items the user wants to keep out of "My items". I've had to put two empty collections in there as sources because a UnionCollection^? requires at least two sources currently (although that could change). The output of 'Not Mine' is fed into a DifferenceCollection^? (descriptively) named 'notesMinusGeneratedEventsMinusNotMine'.

If the user wants to keep a collection out of "My items", that collection would be added a source to the 'Not Mine' collection, and then all items in that collection would disappear from All (unless the item happened to be in allInclusions in which case it would get added back into All). This solution does have the problem that even if a given item is contained in a "Mine" collection, it would disappear from All if it lives in any "Not Mine" collection.

Basing Mine/Not-Mine on items

If Mine/Not-Mine is the property of each item (as opposed to the property of a collection), we then have a few more choices:

[Choice 2, "spheres attribute is a list of strings"] We could create a list attribute on ContentItem^? named 'spheres' to keep track of which 'spheres of life' (Home, Work, Public/NotMine, Private/Mine, etc.) a given item belongs. If this attribute was a list of literal values, then we could add a FilterCollection^? to grab the "Mine" items; that FilterCollection^? would get inserted into All's sources tree, probably between notesMinusGeneratedEvents and allSource.

[Choice 3, "spheres attribute is a ref collection"] Similar to Choice 2, except the 'spheres' attribute is a ref collection; we could add a Kind named 'Sphere' (or something), create instances of that Kind, and associate items with those Spheres via bi-directional ref collections. I suppose we could use a FilterCollection^? again as in Choice 2, but that doesn't take advantage of the ref collection.

[Choice 4, "use ListCollections^?"] Instead of defining the Sphere Kind, we could just use ListCollections^? to represent the various spheres, and add/remove items to the appropriate ListCollections^?. A specific ListCollection^? named "Mine" would be fed into the All collection's sources tree somewhere.

[Choice 5, "use a 'mine' boolean attribute"] The simplist solution seems to be just adding an attribute to ContentItem^? named 'mine' and use a FilteredCollection^? representing all 'mine' items.

Open Questions

When creating new items, do we want to always have to explicitly say an item is "Mine", or should that just be the default? An item could be "Mine" unless explicitly tagged as "Not Mine".

For Choices 3 and 4, Is it too much overhead to maintain huge ref collections?

For Choice 2, is it expensive to run the FilterCollection^? expression?