Build, Release and QA --------------------- *Weekly checkpoint* Bear spins: http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007565.html Dan tests: http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007584.html
*Test case review* Philippe sent feedback on Dan's test specs. Philippe suggested "factorizing" the test cases to be easier to read and maintain. http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007571.html Aparna answered Philippe's questions about the specs: http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007576.html Dan likes the idea, but noted Mikeal and Aparna expressed a need for an itemized listing. Perhaps a "factorized" script or listing could generate the full list? http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007582.html Dev --- *Reminders* Grant refactored reminders. He split "reminder" functionality into 2 kinds, Reminder and RelativeReminder. The former handles absolute reminders, the latter "relative" reminders that depend on calendar logic, in particular recurring events. He also rearranged the reflists and logic that track expired/pending reminders. Grant also made some tweaks to Reminders and recurrence, to help with the future goal of avoiding generating trivial occurrences. For more details: http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007564.html *Sharing API for edit/update* Morgen checked in code to be used for serializing and deserializing items, to be used in mail-based edit/update sharing (also potentially useful for other p2p sharing). He pointed at the API documentation: http://wiki.osafoundation.org/Projects/SharingProject And sample usage: http://viewcvs.o11n.org/chandler/trunk/chandler/parcels/osaf/sharing/EIMML.txt?view=markup Summary repeated in the message: http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007572.html PJE pointed out that an item version <= last version number seen from peer isn't really an error condition. An out of sequence email should be ignored. Morgen explained that he raises an exception to give the caller a chance to react to the situation, alerting the user or whatever. PJE recommended not alerting the user with details they can't act on. (Props exchanged all around). http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007579.html Jeffrey asked for more info on filters. PJE pointed at Sharing Record API doctests, in particular "Filters" and "Filter Arithmetic". Filters suppress change information for one or more EIM-level fields. http://viewcvs.o11n.org/chandler/trunk/chandler/parcels/osaf/sharing/EIM.txt?view=markup *Decoupling "from" and "send as" in email: byline implementation* Bryan Stearns gathered a bevy of bugs related to the byline. He listed out the bugs and summarized his strategy for approaching them. http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007581.html - Make the MailStamp's "From" field distinct from the "From" and "Reply-To" headers on the email message. Bryan is renaming MailStamp.fromAddress to "sendAsAddress" (From: header on outgoing message) and later adding a "fromAddresses" that handles the list of addresses for the "From" field in the UI. Brian Kirsch explained that he'd like to refactor MailStamp to be a generic CommunicationStamp (with Mail annotation or link to MailItem), separating traditional mail type logic from Chandler specific logic. This remains a long term goal -- he agrees with Stearns' approach for Preview. Stearns noted that flexibility is required between layers: mail-service message, MailStamp addressing fields, and UI presentation. We reuse one item for all communications in a conversation. An item you send may later in time be updated by an email you receive -- the UI displays different fields in those different cases. (Stearns gave an example later in the thread). Either the UI needs to display a different attribute, or the mail service layer needs to populate the attributes differently. Stearns and Kirsch agreed to talk through this further. - Preserve not-well-formatted email addresses. Stearns proposed treating an email address with no "@" as a valid email address with no "full name", so that round tripping through the persisted item would work (no parsing, no validation). Kirsch pointed out that the only time an email address needs to be valid is the moment before a send. Kirsch proposed a detail view check right before calling the mail service to send the item. Kirsch noted that getEmailAddress() is inflexible, he gave an alternative code snippet. Kirsch observed that incoming mail addresses may not be formatted correctly as well. Stearns proposed setting a flag on EmailAddress to indicate it needed correction in the UI. He noted that the property would be shared by anyone using the EmailAddress, which may or may not be appropriate. An alternative would be to capture rejected addresses in xxxBadAddress attributes, which didn't smell right as a strategy. The above topics all found here: http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007586.html Stearns argued that the detail view can't do much to check address validity. Reid pointed out that we need to parse it for multiple addresses. Stearns agreed, but didn't commit to handling that with this crop of bugs. http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007588.html Stearns and Kirsch agreed the X-Chandler-From header is no longer needed with the EIM records attached to the message. Davor pointed out that Outlook uses custom headers for a similar feature. http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007589.html *Python performance* Heikki noted a 9% difference between "0 < 1 < 2" and "1 > 0 and 1 < 2". Likely only useful in a frequently called tight loop, but hey, easier to read in any case. http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007592.html Meetings, Miscellaneous ----------------------- Adam gave info on a Cosmo QA session to test out the migration to Cosmo 0.6. Of note, Cosmo paths changed from /cosmo/home/<username> to /cosmo/dav/<username>. Documentation about bookmarkable URLs: http://wiki.osafoundation.org/Documentation/OSAFBundleEndUserManual#Bookmarkable%20URLs http://lists.osafoundation.org/pipermail/chandler-dev/2007-January/007583.html Chandler meeting: http://wiki.osafoundation.org/Journal/EngineeringMeetingNotes20070201 Apps team status: http://wiki.osafoundation.org/Journal/AppsMeeting20070201 Darshana is back from her vacation in India. She has a bit of time, and is willing to help out with bugs/tasks. http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007590.html _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
