[Chandler-dev] [Sum] Jan 22 - 28

[Katie Capps Parlante]

Remember January? Re-live the magic!

Build, Release and QA
---------------------
*Checkpoint*
Bear spins:
http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007526.html
Dan tests:
http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007533.html

*Tiger compilers*
Jared noted a discrepancy between TigerBuildNotes and the actual
behavior of "make compilers". The documentation says gcc/gcj 4.1 is
expected. Andi noted that the documentation is wrong, 4.0.2 is in fact
the correct compiler to use for Intel Mac OS X.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007540.html

*PyICU upgraded with charset detection*
Andi upgraded to ICU 3.6 and added wrappers for new charset detection APIs.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007552.html

*Bug diagnosis*
Andre ran into a repository error, which Grant and Andi recognized as 
Bug 7895. Andi had a fix pending.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007561.html

Dev
---
*Recurrence à gogo*
Grant committed his branch with recurrence work -- improving
recurrence's relationship to triage status, collections, and the
dashboard. Recurring events in the dashboard now present occurrences in
"Now", "Later" and "Done" sections. Changes to a recurring event's
attributes now apply to modifications. (A "modification" is an event
where an attribute was changed and applied to just that event, not the
whole series. Formerly, these were treated as exceptions in the series
and were not modified when subsequent attributes changed). The domain
model changed a bit, such that occurrences no longer store attributes
that have the same values as the master event. Grant wants to look at
removing trivial occurrences (occurrences that are not "modifications")
altogether, in hopes of improving performance.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007528.html

*Empty added to Repository*
Andi added a NilValue type, which has instances Nil, Default and Empty. 
Of particular use is Empty, intended for use as a default value for 
collection or ref collection attributes. (This was discussed in an 
earlier thread, as a mechanism for avoiding generating lots of empty 
lists for items that don't use the attributes). Empty is immutable and 
behaves as a null iterator, sequence and mapping. Code that accesses 
attributes that use it does not have to check for a value or that it is 
not None. Code that changes the collection does have to check for a 
mutable collection. More details on usage:
http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007530.html

Bryan pointed out that comparing to "Empty" is not the right test for 
looking at whether or not the collection has no items (it might be an 
empty mutable list, say if the last item has been removed from the 
list). Andi agreed, explaining that it is safe to write "item.attribute 
is Empty" vs "item.attribute == Empty". Testing for collection 
emptiness, better to use len(item.attribute) or just "for blah in 
item.attribute:". len(Empty) == 0 and list(Empty) == [].
http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007532.html

*Change propagation and the dashboard*
Jeffrey observed that changes to master recurrence items were failing to 
fire notifications in the table, at least for read/unread. He noted that 
it now works correctly for changes to displayName, after a repository 
change.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007537.html

Andi explained that he changed the order of reaction-to-change 
invocations, causing system monitors to happen first, so that indexes 
are updated properly.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007538.html

Bryan, Grant and Andi discussed options. Time-travel to February, where 
Jeffrey nicely summarizes the discussion: the repo could be responsible 
for a clean propagation of notifications to inherited values, but that 
might have a perf hit. Future Jeffrey observed that changing the 
displayName somehow causes all occurrences to refresh. What about adding 
an explicit Refresh when the dashboard's attribute editor makes a change 
to master events?
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007701.html

Also of note in this discussion, Grant argues that we're seeing an 
instance of a larger problem: findValues(), collection indexing and 
notifications should be aware of inheritFrom/To. He asked why have a 
higher level, parallel API for findValues() -- are there cases where we 
don't want inheritance followed? Andi explains that he'd have to go 
check all instances of occurrences to see if they have a new value so 
that they don't get false notifications. Andi explained it would be easy 
to implement, performance is what he's worried about. Perhaps that would 
be mitigated by removing trivial occurrences.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007545.html

*No data loss*
Jeffrey asked about how ics sharing (webcal, CalDAV) and ics import fits
into our goal of no-local-data-loss. Do we preserve local changes to 
events if they conflict with import or ics sync?
http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007546.html

*Moving sharing-specific attributes out of ContentItem*
Morgen proposed creating a new stamp: SharedItem. This stamp would take 
existing attributes "shares" and "sharedIn" away from ContentItem, and 
would manage an item's pending conflicts. One wrinkle: how to avoid the 
core pim code having a dependency on the sharing layer? 
(isAttributeModifiable needs access to the sharedIn attribute).
http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007547.html

After some discussion in the thread and on IRC, Phillip and Morgen 
decided to:
- make sharing a stamp
- make ContentItem delegate isAttributeModifiable to stamps
- add a default isAttributeModifiable to Stamp
- sharing code adds/removes Sharing stamp based on sharing status
Phillip suggested that isAttributeModifiable might be able to go away 
once we have conflict resolution implemented.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007550.html

Morgen implemented this strategy, removing sharing-related dependencies 
from most core pim code (exceptions explained for timezone and 
occurrence code).
http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007556.html

Noted interlude, Phillip explained the difference between an Annotation 
and a Stamp: a Stamp is an Annotation with extra features:
(1) add() and remove() methods to be explicit about annoation being in 
use for particular instances, (2) support for initialValue, set at add() 
time, and (3) Stamp(anItem).stamps attribute gives the active stamp 
wrappers, has_stamp() function to determine presence of stamps.
Annotations don't need these features because they are always on, not 
added and removed. (The data is pretty much the same, but the Stamp 
class is needed to access the features).
http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007551.html

Meetings, Miscellaneous
-----------------------
Apps team meeting:
http://wiki.osafoundation.org/bin/view/Journal/AppsMeeting20070125

Coming soon: February!