0.7 Collections and Notifications

We had two meetings last month about collections:

• CollectionsMeeting20060213
• CollectionsMeeting20060214

I reviewed those notes, as well as a recent thread on collections work that has been done:

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

This writeup is an attempt to summarize the requirements and other agreements: possible fodder for a collections spec. Alec is the collections owner (work done in the layers above the repository), and Andi is the owner of the collections and notifications work done in the repository.

Overview

The basic utilities for building a collection of items will live at the repository layer. The repository layer will provide a comprehensive set of APIs for change notifications, including notifications about changes to collections. Bugs and tasks associated with this work live in the "Repository" component. Recent documentation about collections and notifications at the repository level:

• Collections repository blog post
• Notifications repository blog post

Some layer above the repository will implement "user level collections". User level collections (ULCs) represent what the user understands to be a "collection". Bugs and tasks associated with collection work above the repository live in the "Collections" component.

The detail view imposes some requirements on both notifications and "user level collections", noted below. The DV is perhaps a representative example here, the requirements generalize to other contexts.

Collection Requirements

• Collections need to be items
  • We want to be able to have references to them
  • We want to store data on them

• Collections should be able to be ordered. Collections should be able to have multiple orderings for different contexts.

• We need the notion of a "user level collection" (ULC)
  • A consistent API for ULC's
  • Given an item, we need to be able to know (efficiently) what ULC the item is in.
  • We need to be able to store "user level" attributes on ULCs

• The detail view should not need to know about the structure of the sidebar.

User Level Collections

These are collections that the user has some awareness of.

• ULCs may show up in the sidebar, but not all ULCs will always show up in the sidebar.
• ULCs may show up in future uis (collection browser)
• ULCs usually exclude "trash" items
• ULCs have "add" and "remove" methods (although some of them might be read-only in some contexts)
• The user is aware of ULCs at various points of the UI, including the sidebar, the detail view, etc.

Detail View Notification Requirements

• The detail view needs to be able to find out when an Item's attribute changes, independently of collections (Item notifications)

• DV needs a notification when an attribute that the DV cares about before the rest of the UI has a chance to update
  • i.e. idle loop, wx events, keystrokes
  • its hard to ignore async notifications that have been overtaken by events -- implies a requirement for synchronous notifications

• DV doesn't just want synchronous notifications for changes made in the same view. When changes are pulled from another view on refresh(), the DV wants to know right away, not wait for the idle cycle.

Item notification requirements

• Detect changes from a different view, on refresh()
• subscribe only to changes for a certain list of attributes, not all attributes
• notice collection membership changes (what collections is this item in? has that list changed?)

Proposed decision on sync/async model

note, recording this as historical info, we ended up with a variant, see Andi's comments

• We will delete the "deliverNotifications" method
• The repository will implement synchronous notifications
  • Note, this does not imply that view A synchronously notifies view B about changes. Changes that occur in other views will be notified after refresh, synchronously.
• Problems:
  • Noted that we can run into problems with recursive notifications, especially during construction. Solution: we have a framework for ignoring some notifications.
  • Noted that the order of notifications can be a problem, particularly with deleted items. This can also cause redraw problems. "Hints" are the proposed solution to this problem.
• We are delegating the problems above to the application layer.