Collections Meeting

Facilitator: Katie; Notetaker: Jeffrey

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

Table of Contents

Agenda

• Requirements (25)
• Layering (25)
• 0.7 work (15)
• Next steps (5)

Requirements

• Propagate notifications
• replace queries
• persist results
• provide an order for collections
• provide multiple orders
• given an item, know what "user level" collections the item is in
• Store meta-information (attributes) about "user level" collection
• Collections need to be items
  • references to them
  • store data on them
• consistent API for user level collections
• Given an item, know (efficiently) what ULCs the item is in (see discussion later in these notes)
• Detail view should not need to know about the structure of the sidebar
• [future] Clean API to consistently determine collection capabilities
  • [future] alternately, a uniform API, KindCollection^? "add" does a different thing?
  • [future] would be nice to preserve add as having no side-effects

What is a user-level collection?

Not obvious what a "user level collection" is, ideas:

• has add and remove
• lives in the sidebar
• can they be read only?
• supports drag and drop
• excludes trash items
• is trash a ULC?
• a ULC "sits above the line"
• user interacts with it

Where is the line where ULC lives?

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

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

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

- - - ULC above this line? - - -

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

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

• Like to have an attribute (flag) on a collection, which "turns on" efficient tracking of whether an item is in the collection
• The "add and remove" requirement doesn't apply to read-only collections, of course

Detail view requirements

• Find out when an Item's attribute changes, independently of collections : Item notifications
• Currently, it's a requirement that notifications be synchronous, but Bryan's willing to consider simpler solutions

Notification requirements

• Blocks in the Detail View:
  • have contents (Item or Collection)
  • attributes that affect presentation (for instance allday and startTime)
  • want notifications when those attributes change
  • these generalize to the rest of the ui
• How to handle async notifications? Seems like DV needs synchronous notifications
  • Would like a notification when an attribute that DV "cares about" before the rest of the UI has a chance to update, for instance
    • idle loop, wx events, keystrokes
    • have trouble ignoring async notifications that have been overtaken by events
  • Other blocks have run into this problem
    • can always make sync notifications look async
    • sidebar, etc. : poll for noticications
  • Not just synchronous for changes made in the same view, also want a sync notification for changes coming from refreshing changes from another view
  • Nothing like this is currently provided by the repository
    • why were notifications originally made async?
    • Didn't really know the requirements perfectly, the existing code is an agglomeration of different hacks, "Frankenstein"
    • Thought perhaps delaying notifications could combine duplicates? Currently dupes are ignored at a higher level
    • Performance was an issue, synchronous would be slow, at least in the abscence of hints
      • doesn't seem like hints currently solve the problem

Item notification requirements

• Should "item notifications" have the same subscription and delivery mechanism?
• Detect changes to the given item
  • from a different view, on refresh
  • subscribe to just changes to a certain list of attributes, not all attributes
  • collection membership changes

Andi's current problem

• UI creates sidebar collection gets created at start time, commit of changes is lazy, creates race condition
• Race condition timeline:

- - - - - - - - - - - - - - - Thread adding notes to repository based on IRC
  /\      adds to /\    |
  |       collection    |
 refresh          |   commit
  |               |     \/
------- Timeline ------------
    |    |  |      |
    |    |  |      |
    |    |  |      |
    |    |  |      |
    \/   \/ \/     \/
- - - - - - - - - - - - - - - UI thread
/\ 
|
newIndexCollection(new) is called, UI displays the new collection,
but it's not committed

Summary of the timeline: Sidebar collection tree is partially committed

• collection math happens at the repository level?
• Could be a problem if the new collection is a filter collection and an item changes to match in another view
• Refresh notification could solve the filter collection problem
  • Detecting updates from another view
  • forcing collections to update themselves based on refresh from other views
    • less work for changes in same view, different code path for changes coming from other views

Discussion about moving notifications below the line

API the repository provides to the app:

• subscribe to collections or attributes
• get notified synchronously (for in view changes)
  • at refresh time, essentially playback changes

App domain

• handler takes events
• app prunes

If notifications move below the line, they can't rely on onIdle. But onIdle currently calls deliver notifications, does it need to?

• deliver notifications calls "map changes"
• could just call view.refresh()
  • There's lack of clarity in the meeting about whether this would work
  • Everyone wishes that notifications would be delivered synchronously, if that changes, can deliver notifications be deleted?

Proposal about notification changes

• delete "deliver notifications"
• Repository:
  • synchronous notifications
    • in the view
    • on refresh: playback of changes
• problem - recursive
  • get notifications during construction
  • solution - have a framework for ignoring some, or certain, notifications
• problem - order of notifications
  • items that are deleted
  • redraw too much
  • solution - hints
• Delegate above problems to the Application level
• Agreement in the meeting on the above

Time's up, schedule a follow up meeting

• Tomorrow, Tuesday at 2:15, if there's no design session then

Questions raised

• Does domain model know about trash? yes, it seems general enough
• How many ULCs? 100s?
• What is not implemented today
• Sidebar scalability (performance)

Next steps

• meeeting tomorrow
• Andi proceeds with plan (uncover new info)
• writeup for list
  • sync model
  • highlight requirements, make detailed and explicit

Next meeting's notes

CollectionsMeeting20060214