[Chandler-dev] [Sum] annotating selection

[Katie Capps Parlante]

When writing the weekly summary for March 27 - April 2, the summary for 
the "annotating selection" thread grew long enough to deserve its own 
message. This is sort of an experiment in seeing if this kind of summary 
is useful...

Alec made a proposal to get rid of IndexedSelectionCollection (ISC). The 
argument follows:

ISC's are created when a "SmartCollection" sidebar collection is 
selected. A new ISC is created for every combination of 
collection/kind/filter. The views need to refer back to the original 
collection for color and other information. The ISC is used by the 
summary table/calendar views for these purposes:

1. maintains the per-view selection, and persists the selection
2. container for storing indexes for source collection items
3. persistent storage of the current sort

Alec's argument is that the second 2 are not really valuable, and that 
the third can be handled with "SelectionCollection" annotations (or some 
variant).

Discussion about #2 (ISC storing indexes for source collection items)
-------------------
Alec argued that indexes should be on the original collection, not on 
derivative collections.

John pointed out that some mechanism is required for different kinds of 
sorts -- he gave different locales as an example.

Alec argued that this is a degenerate case, and that building an extra 
layer of indirection is premature generalization. Alec argued we should 
view an index more statically -- store different indexes ("date", 
"displayName") instead of tweaking the indexes.

John remarked that he'd prefer not to store indexes by a well known 
name. He'd like to be able to ask for an index by naming the properties 
(building up a string or whatever). Indexes could be cached.

Andi pointed out that if we needed to store indexes for multiple locales 
we could store multiple indexes, one per locale, all installed on the 
same collection and named appropriately.

Andi asked if we really need to support multiple locales in the same ui. 
Brian responded 'no' -- the indexes should use the sort order associated 
with the "primary" locale. (There is a more complicated 'yes' answer, 
"backup" locales are used for 3rd party parcels that don't support the 
primary locale, but this does not affect the sort order).

Discussion about #3 (ISC persisting the current sort)
-------------------
Alec argued that the current sort should be owned by the cpia block or 
widget referencing the collection, not an intermediate collection.

John pointed out that we want a single block to be able to view many 
different contents. John argued the selection is more closely tied to 
the index of the collection than the Block.

Alec explained that his proposal would indeed allow a single block to be 
used with different collections. Alec is proposing that the block store: 
(a) contents, (b) name of the current sort index ("date") and (c) name 
of the index being used for selection. The source collection would store 
the different indexes by name. The block could swap contents, and the 
indexes would be stored on the source collection. (see ascii art below)

Discussion about #1 (per view mechanism for persisting selection)
-------------------
Problem to solve: how does the selection update automatically if it is 
not part of the main collection? Annotations?

Alec gave some sample code in the original thread, and drew a diagram 
that looked something like this when I asked him in person:

source collection    <-- (contents) block
  --> "date" sort index               "current sort" --> "date"
  --> "displayName" sort index        "current selection" --> "dashboard"
  --> "dashboard" selection index
      (numeric, unsorted)

Alec is proposing one consistent index that is used for selection in a 
given block. The selection index would be independent of the sort 
indexes. Its possible that we lose some efficiency, but we haven't yet 
proved it necessary to maintain them together.

John asked if this is the tradeoff (waste less space at the expense of 
slower performance):
- changing the selection for many items would be less efficient
+ if 2 different blocks use the same sort, we could reuse the index
John thinks it a mistake to give up on handling large lists efficiently.

http://lists.osafoundation.org/pipermail/chandler-dev/2006-March/005624.html