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!
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
