Collections Meeting, continued

• Yesterday's meeting notes at CollectionsMeeting20060213

Facilitator: Katie; Notetaker: Jeffrey

• Participants: Alec, Andi, Bryan Stearns, David, Jeffrey, John, Katie, Ted

Table of Contents

Agenda

• New issues
• Sidebar overview (15)
• Sidebar scalability (15)
• Layering (15)
• 0.7 Work Owners (10)

Should subscriptions be persistent?

• The are currently persistent
• Synchronous: more oddball cases
• UI: more convenient to not persist them
  • subscribe only when widget is displayed

• A collection with no UI would want to be without remembering to subscribe each time (no known case today)
• Perhaps an option to persist them or not?

Agreed: Expose an API to allow persistence to be explicitly prevented.

Clients of blocks don't have to worry about it.

Collections in the Sidebar Overview

• not captured, drawings of relationship between sidebar collections, other collections, and blocks

IndexedSelectionCollection --- contains --> SidebarCollection (based on ListCollection)
                                            / | out of the box, contains
                                           /  \/
                                          /   AllCollection
                                         /    TrashCollection
                                        /
                                       \/
          IndexedSelectionCollection (theoretical alternate order and selection for the SidebarCollection)

• Use event to add item to sidebar in UI

Relationship between IndexedSelectionCollection and the SidebarCollection

• IndexedSelectionCollection wraps (contains) the SidebarCollection. It also contains additional metadata about
  • order
  • selection

Collection scalability

• problem that creating an index loaded all items in collection
• lazily creating all indexes slow
• on the fly indexing unions and filters on large collections can't scale
• filter collection causes items to be loaded
  • Non-recurring notes filter collection forces loading of all items, Grant might have fixes
• You could make very expensive collections
  • Take care to create them carefully

Ideas:

• Filter collection instead of boolean logic?
• Is it possible that the all collection will go away once the dashboard is implemented?
• Smartfolders on email might be slow, but that could be fine, given appropriate UI
• avoid scanning all items
• Hard to optimize a query based on boolean set-logic
  • combine it somehow?
• push set operation down to avoid loading items
• new API, retrieve a value without loading items
• anticipate indexes
• Building all the indexes we might need might take a lot of disk space
  • but that may be a fine thing for a data intensive application
• Build indexes on another thread
• give user feedback about building index
• Huge win to get rid of "isGenerated"

Parcel programmers don't (shouldn't?) need to understand the structure of complicated collections

Adhoc attributes and tagging

• Emails Bob has sent me, don't want ones in trash
• Ask if you can empty trash beforehand?
• offtopic, stepping back to agenda

Layering

    /--------\
    |   App  |
    \--------/

/------\ /----------\
| CPIA | | Services |
\------/ \----------/

    /--------\
    | Domain |
    \--------/

- - - Where does ULC live above this line? - - -

    /--------\
    | Parcel |
    \--------/

    /----------\
    |Repository|
    \----------/

What gets moved below the line first

• Notifications first, because they're semantic free
• Protocol that wraps sets
• Abstract collection (or moral equivalent)

Why so many classes?

• One collection class/kind?
  • question about notifications
  • would have to change set, if we did this would it cause problems
  • this would've been hard in parcel.xml, might be feasible now that parcels are written in Python
• Proposal: One collection class
• or Proposal: One mixin protocol for collections
• Problem: collection classes missing APIs

• Issue: sets are not mutable, if not, have to throw them away.
  • To achieve this, want to restructure collection tree dynamically, which might cause a problem with having one class or protocol for collections

• Andi continues to own repository level of course
• Apps team takes on
  • ULC (might be a protocol)
  • InclusionExclusionCollection
  • ListCollection

0.7 Work and owners

• Apps team work
  • notifications
  • collections

• Specific problem What collections is an item in?
  • Andi sets up
  • Bryan Stearns hooks it up in the app
• Item notifications (talked about yesterday)
  • Andi
  • Apps team

Questions

• Should API for turning off persistence of notifications be above or below the line?
• When should index be created on sidebar collections?

• AllCollection^?.png: