Notes

Topics/Issues for Collections code/design review

• Do we understand the use cases for notifications vs monitors
  • push vs pull
• The expression language for filters
• User/System Collections versus generic (non-ui but application level) Collections
• Switch to turn notifications on and off
• Using collections to implement Mine/NotMine
• KindCollections^?/extents/etc.
• Caching/indexing

Code/design review logistics

Gotham and the conference bridge are currently reserved from 1-3 Thursday (9/15).

• collections implementation
  • http://viewcvs.osafoundation.org/chandler/trunk/chandler/parcels/osaf/pim/collections.py?view=markup
• set implementation
  • http://viewcvs.osafoundation.org/chandler/trunk/chandler/repository/item/Sets.py?view=markup
• client code that uses collections
  • http://viewcvs.osafoundation.org/chandler/trunk/chandler/parcels/osaf/app/__init__.py?view=markup

Design review next actions

• Ted will write up a proposal for a cleaned up notifications API.
  • common callback signatures, etc
  • will try to convert notifications to pull style everywhere for better consistency.
• Morgen will try out an implementation of Mine/NotMine based on thinking of "Mine" and "NotMine" as two possible spheres, where we may have future spheres. He'll look at using sets/collections as the basis for spheres.
• Ted will work with PJE to add a method to the schema API to get the KindCollection^?
• Ted to move onValueChanged lazy creation model to constructors
• Alec will use the annotations feature to handle color and other style information for collections.
• Phillip will go ahead with implementing the annotations proposal, so that Alec and others can use it.
• Once some cleanup is done, we'll move collections "below the line" to think of it as living in the repository, not the pim domain model. To receive all notifications, clients of the collection will have to use the mapChanges api (or some equivalent) to poll for them.
• Andi will talk to Heikki about alternatives for the certstore use of collections.
• Andi will make "readOnly" an attribute aspect, so that it can be made available by the schema api. We will allow the schema api to change "readOnly" attributes (including "update").