[Chandler-dev] [Sum] March 26 - April 1

Katie Capps Parlante capps at osafoundation.org
Thu Apr 12 22:35:21 PDT 2007


Build, Release and QA
---------------------
*Weekly checkpoint*
Bear spins:
http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007941.html
Dan tests:
http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007943.html

Dev
---
*Performance*
Andi added a new API, Item.getLocalAttributeValue(name, default) which
is speedier than Item.getAttributeValue(name, None, default, True). This
speeds up import. Andi observed that import makes this call 3.6 million
times importing his 446 event calendar.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007946.html

Andi moved view.findValues() to C -- called half a million times
importing his 446 event calendar.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007948.html

Andi moved view.findInheritedValues() to C -- called 521,580 times
importing his 446 event calendar.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007949.html

Andi implemented ICUtzinfo and FloatingTZ classes in C. These classes
have 750,000 calls to their methods while importing the 446 event calendar.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007954.html

*translator's loadItemByUUID deprecated*
Morgen replaced the method above with translator.withItemForUUID. Taking
the same arguments, the method can be used:
- non decorator: the method will not return the item
- decorator: for the case where your importer needs access to the item
being loaded or created. You'll need to write a nested method -- a
'deferred' that won't get called right away. In the case of
multiple-inheritance, the code might need to wait to upgrade the type of
an item. Morgen includes sample code:
http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007950.html

Grant has a minor correction for the sample code):
http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007953.html

*Master password*
Heikki landed the password encryption feature on the trunk (see File >
Protect passwords). If you need to change personal parcels to load
account information, you'll have to change them.
http://wiki.osafoundation.org/Projects/ParcelLoading
http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007955.html

*Dump et Reload*
Heikki brought up some questions about Dump and Reload, and asked for
replies on the design list.
http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007964.html

*Pure occurrence*
Andi and Grant observed needless indexing and reindexing of pure
occurrences in master indexes used by the dashboard. Andi defined a
"pure" occurrence as having a non None value for 'occurrenceFor' and a
None value for 'modificationFor'. Andi observed that *all* occurrences
created when importing an .ics file or restoring cosmo collections are
"impure". Andi asked if this was expected. (Andi describes a change that
improves performance of operations involving pure occurrences, as they
are no longer indexed and reindexed).
http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007959.html

Jeffrey noted that trivial occurrences are mainly needed by the calendar
UI. Grant explained that import should have no reason to create "pure"
(a.k.a. trivial) occurrences. Grant said he'd expect importing a single
master event to create at most 3 modifications. (He noted auto-triage
might alter this). He suggested importing a calendar containing 1
recurring event, looking at how many times EventStamp._createOccurrence
is called. (Parenthetically, he described a createOccurrence related
leak in the calendar fixed with Bug 8472).
http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007962.html

Meetings, Announcements
-----------------------
IRC QA session, validate resolved desktop bugs:
http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007945.html

Feature complete checkpoint meeting:
http://lists.osafoundation.org/pipermail/chandler-dev/2007-March/007958.html


More information about the chandler-dev mailing list