Build, Release, QA ------------------ *alpha3* We cut alpha3 RC 1 on Friday July 28 after fixing the infamous Bug 6266 (new events not showing up on calendar canvas). To relive the last throes of the release, check out the thread: http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006441.html
*wx build* Bear and Robin updated the build steps for the updated wx build: http://wiki.osafoundation.org/bin/view/Projects/WxBuildNotes *Intel Mac and Alpha3* Mitch had problems running the Intel build of alpha3 on his Mac mini. In a side discussion, Andi reminded everyone that PyLucene doesn't run on Rosetta (the PPC emulator on Intel Macs), due to the libgcj garbage collector and its relationship to threading. Bryan Stearns logged a bug (6413) to throw an alert if one tries to run a mac build on the wrong architecture. (Sheila resolved the bug after the problem went away with a reinstall). http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006488.html Intern, SoC projects -------------------- *Contacts* Ernesto gave an update on the contacts parcel, noting that he committed new code. The Test menu option works, and you should be able to import a dictionary of vCards. Jeffrey tried it out, and gave some feedback about packaging, adjustments to work with the current codebase (displayName and wx.HIDE_READONLY), and usage of vobject. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006512.html Ted also tried it out, and offered a patch incorporating Jeffrey's comments. Ted ran into problems importing his Mac address book, but these turned out to be vObject problems. He noted that better reporting/debugging information would be useful. http://lists.osafoundation.org/pipermail/chandler-dev/2006-August/006536.html *Tags and topologies* Philippe opened up a discussion about "tags" being hierarchical. He observed that the success of folksonomies may be due in part to the lack of a formal hierarchy. He asked about other kinds of structure to relationships between tags that might be deduced. He gave an example where a local hierarchy could be observed and an option given to "turn it off" -- e.g. "work" related tags. Philippe observed that Xun's work might be applied to some of these ideas. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006482.html Dev projects ------------ *Sharing Performance* Lisa did some analysis on the performance of sharing. She took a "bottom up" approach and started looking at TCP and SSL connection characteristics. She used a May 21 version of Chandler (~alpha2) and hit cosmo-demo, looking at "publish", which took 5 minutes. She used SSLDump to analyze the trace. She noted several TCP/SSL issues to investigate: (1) 7 separate SSL connections during publish, where only 1 should really be needed. Pass one PyOpenSSL object around instead of instantiating new ones? (2) Within one SSL connection, traffic is slower than expected. (3) Something weird going on with one of the connections in the trace, 2 minute delay before the client sends data. (4) The client hung up on one of its own connections (the delayed one). Lisa posted the output to a wiki page. http://wiki.osafoundation.org/bin/view/Journal/PublishConnectionAnalysis http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006439.html Grant gave more detail about Lisa's observations. (1) An extra connection occurs because Chandler uses separate connections for the CalDAV (many .ics files) and Chandler specific (.chandler subdirectory) shares. This adds roundtrips because we're not using information learned earlier, and could be avoided. Two more result from Cosmo returning a 501 and closing the connection (Bug 5340, Bug 6048). The others appear to be cases where the client thinks the server has closed the connection. (3) Grant doesn't see the delay when using openssl from the command line. Chandler appears to be writing the data as soon as it finds out the connection succeeded. (4) Grant observed that it looks like the client tries to close the connection very soon after sending the TLS handshake. Perhaps M2Crypto (the TLS implementation) and twisted (TCP) aren't in some way out of sync wrt the state of the connection. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006440.html Heikki explained a few ideas for optimization of our use of SSL. (1) Reuse the SSL context, we don't need a new one in practice. Easy to do. This adds a fraction of a second in overhead. (2) Reuse the SSL connections. Harder, and could inject security bugs if done incorrectly. May uncover M2Crypto bugs. There may also be bugs in the Twisted+M2Crypto+Chandler integration. Heikki proposes analyzing the unencrypted connection. When comparing cosmo-demo (SSL) and qacosmo (unencrypted) he didn't detect significant differences. He would be surprised if most of our sharing performance problems come from SSL. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006445.html Lisa argued that since the connections are serialized, and one of them spent 2 minutes doing nothing before the handshake, this is probably a worthwhile problem to go solve. Grant isn't seeing the 2 minute delay Lisa noted, even publishing the same calendar. Perhaps an artifact of using an older version? http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006446.html Grant explained one of the separate connections determines what the server supports (Sharing.publish()) and another finds a unique collection name to share (Sharing.getExistingResources()). Heikki proposed caching server capabilities. He also proposed trying to publish with some name and then fail/retry with a different name. Grant agreed that we should use a single connection, and noted that Heikki's suggestion was more robust anyway. Grant observed another wasted connection: a connect() API on SharingConduit is called near the start of publishing a share, and the current implementation throws out the old connection (without closing it) and creates a new one. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006451.html Heikki logged 4 bugs for issues Grant found. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006452.html *Reminders* Grant picked up the reminders-outside-chandler discussion again. He's inclined to go with the two-processes with repository access approach. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006458.html Bear gave details on OS specifics for launching an app at startup: http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006462.html Reid gave a link for info on OSX launch daemons: http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006463.html *redirectTo futures* Bryan Stearns opened up the conversation again about getting rid of redirectTo. He pointed to problems with keeping indexes up to date (Bug 6387) and dashboard spec requirements for sorting columns that don't neatly line up with attributes. He noted that Jeffrey had proposed using onValueChanged for keeping just-for-indexing attributes up to date, and Andi suggested a "bequeathTo" feature. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006461.html PJE noted that many uses of "redirectTo" can go away as we wash out "displayName" usage and implement the "about" attribute directly. Similarly, the others apply to "date" and "who". We could reverse the direction of these relationships, so that the for-indexing attributes (who/date/about) are updated when the "source" attributes (more specific variants of who/date/about) change. He agreed that onValueChanged could be a tool for populating these attributes in more complex cases. He noted that there is overlap with stamping -- annotations may need to detect when a stamp value is changed and update who/date/about or other just-for-indexing fields. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006464.html Grant noted that there is general agreement that we should get rid of redirectTo and use explicit attributes. He expressed concern that onValueChanged could get unwieldy. He'd rather see an API not unlike pim.Calculated where the indexed property is "basedOn" some set of attributes. (He gave example pseudocode in the note). The index creates a monitor to update when changes are made to the source attributes. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006468.html John proposed an implementation where a Python property is used for each source attribute. When the attribute is set, a complex calculation is set off to update the indexed attribute. Grant noted that this idea might work for tightly coupled attributes (e.g. triageStatus / triageStatusLastChanged), but perhaps not for more complicated cases like "next interesting date". In this case the calculation may have to look at several attributes across several stamps, and it would be icky to have that logic spread out across the code base. (Grant's proposal above had the logic associated with the indexed attribute, not the source attributes). http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006470.html *I18n Eggs* Brian Kirsch sent out a proposal for the EggResourceManager API. PJE and Markku gave feedback on the proposal, which Brian incorporated. Proposal linked here, follow the thread for the extended discussion. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006431.html Later in the week, Brian sent the EggResourceManager implementation for review. This project will be hosted by OSAF separately from Chandler, similarly to Zanshin and VObject. It has a bunch of unit tests, which are a good starting point. PJE gave some feedback about packaging, and suggested "EggTranslations" as a name. http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006481.html Andi expressed concerns about ASCII limitations on filenames. PJE explained that this applies only to source code and resource filenames, which need to have ASCII names anyway. Source code files need to be legal Python identifiers, and resource files need to have ASCII filenames to support localizability across platforms (no universal file encoding across platforms). http://lists.osafoundation.org/pipermail/chandler-dev/2006-August/006515.html Meetings, Announcements ----------------------- No apps meeting due to OSCON, status: http://wiki.osafoundation.org/bin/view/Journal/AppsMeeting20060727 Philippe pointed out a dreamweaver alternative (open source) written using wx, called Amaya: http://lists.osafoundation.org/pipermail/chandler-dev/2006-July/006486.html _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
