[Chandler-dev] [Sum] Feb 5 - 11
Katie Capps Parlante
capps at osafoundation.org
Fri Apr 6 18:38:53 PDT 2007
*New wx tarball*
"make" will get you the new wx tarball, with fixes for linux drag and
drop, speedier two finger scrolling, an os x list control cosmetic
issue, and a script recording bug. Also adds missing xrc styles for
*Where is my repository? How can I use different repositories?*
Answer to first question here:
Andi added two new menu items under Test-Repository.
- "New Repository": restarts Chandler with a new repository in the
- "Switch Repository": restarts Chandler with existing repository in the
chosen location. If there is no repo at that location, it clones your
existing repository into the new location.
More details here:
Philippe gave a schedule update, including outlining remaining
phases/deadlines for Preview. (Dates no longer correct, so omitted from
- Feature Freeze (Feature work stops. Performance work starts. Deadline
criteria: no "task" bugs in bugzilla.)
- Code Complete (Major code in, including perf and feature tweaks.
Deadline criteria: perf targets hit, no feature tweaks needed.)
- Code Freeze (All bugs fixed. Deadline critera: no more than 10
blocking bugs to enter final phase.)
QA, bug discussions
John ran a recent build on Vista, which crashed after launching. He was
able to run from the command line without any problems. He also tried
0.6, and ran into various problems (deadlock bug, splash screen).
*Testing data migration*
Aparna sent out a notice about a QA session to test migration to Cosmo
0.6 (in preparation for upgrading osaf.us):
Jared gave more context about how the sessions run:
- osaf.us remains the live production instance. Changes made to
lab.osaf.us are thrown out. You can test your account freely on
lab.osaf.us during the test session without any impact on your real data.
- Only you can access your account on lab.osaf.us. All security policies
protecting live data at osaf.us apply to lab.osaf.us.
- "spot checking" testing helps us validate migration from the Cosmo 0.5
schema to the Cosmo 0.6 schema
Jared and Aparna agreed that the safest path for the test session would
be to test lab.osaf.us with a "fresh" Chandler profile, leaving your
original Chandler pointing at osaf.us.
Andre noticed the end date of a recurrence changing by extending one
day, with no apparent action on his part. Dan couldn't reproduce the
bug. Timezones may be involved. Andre was trying for reproducible steps,
no bug logged.
Andre asked about errors indicating that triageStatus and displayDate
subindexes were out of step (e.g. 'not sorted properly', 'rebuilding').
Bryan Stearns pointed out that we have a bug (7324), but no good set of
steps to consistently reproduce the bug. Andi observed that dangling
refs are getting introduced in the repository somehow (which eventually
lead to the KeyErrors). Isolating a simple set of steps would be
invaluable. Thread starts here:
*Mail in Preview*
Brian Kirsch checked in a major set of email work, and wrote up a
summary of the changes. The goal for preview: allow people to get some
mail messages into Chandler, and assume that the user continues to use
their current email client. Chandler no longer downloads all email from
an IMAP inbox or POP server. It now scans for messages with "Chandler"
headers (mail sent by Chandler clients). It also allows the user to set
up "Chandler" IMAP folders. The user can put emails from into these
folders on their favorite IMAP client, and Chandler will pick them up.
Brian also reworked the Account Preferences Dialog, cleaning it up and
adding features like "autodiscovery". More info in Brian's message:
Katie assumed we were moving plugins from the end-user release. Heikki
gave a proposal for trimming the end-user release, including removing
plugins, and leaving the developer release as is.
Philippe liked Heikki's proposal but expressed concern about developer
resources. Heikki responded that he didn't think most tasks were very
expensive. He mentioned removing menus as a tricky bit, suggesting that
menus should appear automatically if used by any plugin. PJE suggested
accomplishing this by providing APIs like 'getTestMenu(view)', returning
existing menu item or creating and returning it. Plugins which add menu
items can use the return value of the parent.
John noted that many test menu items are useful for tracking down bugs
with users, and would like to see them remain in the end-user release.
He proposed a hidden key combination to toggle the menu. Heikki thought
the test menu code should live in a plugin. John thought the code to
implement the test menu is trivial, so why remove all of it? He gave
"check repository" as an example of something we should leave in. He
thought we could take a pass through the menu to remove some that are
clearly not useful for development.
Katie agreed that some items from the test menu should remain in the
end-user distribution. She asked John for a list of items he'd like to
remain. She noted her alpha5 bug to move "test" code to a plugin,
explaining that she could factor out certain menu items and leave them
in the core. She listed out items she'd like to see available. Davor
added 'save/restore settings' to her list.
John wanted some way for developers to unzip or download the parcels,
from the end-user release. Andi agreed that eliminating the plugins
altogether would be counter productive, though we need to at least do
something to "turn them off" -- don't leave Flickr active in the
background. Heikki explained that disk or download footprint isn't his
concern, he's concerned about plugins that use up memory, slow down
startup, are periodically active on the network, etc.
Brian Kirsch explained that the Egg-Translations plugin is required, and
shouldn't be removed from the end-user (or any) distribution.
Andi proposed renaming 'Experimental' to 'Plugins'. Heikki suggested
'Tools' -- move other items from the 'Test' menu. Katie suggested
'Demo'. She agreed that a 'Tools' menu makes sense for items we want to
keep around in all releases, like "check repository". She explained that
the long term model is not for plugins to be segregated to one menu, but
to be integrated into the app. In the short term we don't have the time
to do that properly. Andi asked: why a plugin for 'Tools'?
Katie started a related thread on the design list.
PJE revealed a misunderstanding on Katie's part. He explained that
plugins are shipped as .egg files, placed in an appropriate directory.
We should think of projects/ much as we think of externals/ -- not to be
shipped with a production Chandler instance (they are part of the
*build*). "Activating" or "installing" a plugin is about putting the
.egg file in the right directory where Chandler can discover it. He
posed the question as: do we want to ship the .egg files and do we want
them activated? He noted a performance gain on startup with the .egg
files vs the projects/ directory -- we could consider building up
parcels/ as an .egg. He explained that "setup.py develop" and "setup.py
install" are the needed tools for plugin development, including getting
the source. setup.py also provides the mechanism for
registering/uploading a plugin. A menu item allowing devs to pull down
plugins from CheeseShop and we have all the infrastructure we need to
develop, distribute, and deploy user-contributed plugins.
Katie asked if we should go the CheeseShop route for Preview. Andi
responded in the affirmative.
Andi and PJE discussed further in IRC, and came up with a proposal.
- Use CheeseShop for publishing plugins
- Don't ship "projects" directory, create "plugins" directory for
- Move indispensable projects (translations) to "external", "internal"
- Add plugins menu to point to CheeseShop
- Plugins menu can scan "plugins" to know which plugins are available
and which are actively installed/running
Heikki described a system similar to Mozilla's: put the plugins in the
source tree if you have write access, otherwise put them in the profile
directory. Something simpler would be ok for Preview. He recommended
looking at the Firefox UI. He observed that Firefox has a huge number of
extensions, and is not sacrificing end user experience or download size.
He's in favor of scrapping everything not needed by the end user.
*EIM and Recurrence*
Jeffrey gave a scenario we need to support: a master event is just an
event, but some modification is also a task. The current plan was to
pass just the master to the translator for export, expecting the master
to yield modifications. Jeffrey asked for a mechanism for sending the
modifications to appropriate translators.
PJE offered two options, storing a second translator to handle
modifications, or calling the same translator and detecting whether the
event was a master event or modification. Jeffrey and PJE agreed the
latter was fine for now, though Jeffrey wondered if this would be
confusing for future parcel writers -- they will be _required_ to
distinguish between masters and modifications for this to work correctly.
*EIM domain model*
A Cosmo thread about EIM and recurrence wandered in and out of this
list. Thread starts in chandler-dev here:
Morgen gave a summary of null related values in EIM:
- None/Null (field has no value): <element />
- Empty (string or list field has an "empty" value): <element
- NoChange (in diff records, field hasn't changed): not serialized, the
absence of an element is an indicator of no change
Morgen asked: if we have a master event with a reminderTime, and a
modification doesn't have a reminderTime, is that field represented as
"None/Null" or "Empty"? Morgen suggests that "None/Null" could indicate
the modification inherits from the master, and "Empty" could indicate an
explicit lack of reminder.
Morgen asked other questions: What does "Empty" mean for an Integer
type? Does a "None/Null" value for "Location" mean we remove the item's
location attribute or set to None? What would "Empty" then mean?
Jeffrey agreed with the proposal: Empty indicates specific removal of a
field, None/Null indicates the field should inherit from the master.
Jeffrey noted there is no way to distinguish between an empty string in
a modification field and removal of the entire field with this proposal,
but thought we could live with it.
Jeffrey and Randy agreed on a strategy for icalendar and EIM:
- DTSTART and DTEND should go in icalendar even if not changed
- DTSTART and DTEND should _not_ go into EIM modification records unless
start time or duration is changed by the modification.
- If an event is created by CalDAV including start/end time for all
modifications, Cosmo should strip away unnecessary times when Chandler
Brian Moseley thought the proposal wasn't quite right. After further
conversation in IRC, Brian Moseley summarized a new proposal. A
modification attribute has three possible states:
- has a value
- has no value (None/null, or <element />)
- is "missing" <element eim:missing="true" />
Only modifications can have "missing" attributes -- this indicates the
attribute should be inherited from the master item. Cosmo will copy the
attribute value from the master when exporting the modification to
iCalendar, CalDAV. Alarms on event modifications can also be "missing".
Morgen sent out documentation about the conflicts API, for use by the
conflict resolution UI. API documentation on sharing wiki page:
Usage in doctests:
Philippe asked if a "field" mapped to an attribute. Morgen explained
that a "field" can be a spectrum, ranging from an entire item to an EIM
field. As a short term step, the current granularity is an item (to
allow testing with the API, which will not change). Once the
implementation is finished it will be an EIM field, which is essentially
an attribute. Morgen gave the record types currently defined. He
explained that at some point we might link fields that need to be
rendered, applied and discarded as a unit.
More information about the chandler-dev