[Chandler-dev] [Sum] July 24 - 30
Katie Capps Parlante
capps at osafoundation.org
Wed Aug 23 19:35:56 PDT 2006
Build, Release, QA
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:
Bear and Robin updated the build steps for the updated wx build:
*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
Intern, SoC projects
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.
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.
*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.
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.
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.
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.
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?
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.
Heikki logged 4 bugs for issues Grant found.
Grant picked up the reminders-outside-chandler discussion again. He's
inclined to go with the two-processes with repository access approach.
Bear gave details on OS specifics for launching an app at startup:
Reid gave a link for info on OSX launch daemons:
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.
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
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.
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
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.
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.
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).
No apps meeting due to OSCON, status:
Philippe pointed out a dreamweaver alternative (open source) written
using wx, called Amaya:
More information about the chandler-dev