[Chandler-dev] [Sum] July 3 - 9

Katie Capps Parlante capps at osafoundation.org
Tue Jul 11 09:40:58 PDT 2006

Build, release and QA
*Nominating bugs for alpha3*
I proposed that the process for nominating a bug for alpha3 should be to 
change the target milestone to '---'. Bugcouncil's process is to review 
untargeted bugs regularly and assign them to a release. Mikeal suggested 
that this should be the process for bringing a bug to bugcouncil's 
attention for any reason, at any stage of the release cycle.

*Adding check() to functional test suite*
Mikeal pointed out that CATS 0.2 will have a "debug level". We could use 
  this as an option to RunChandler, where check() gets run after every 
test for certain debug levels. Implementing this will be easy with the 
new framework. We are a few days from being at 0 bugs in CATS 0.2, so 
perhaps wait on this before adding check() to each test script.

*Cats 0.2*
Mikeal announced that we're near completion of CATS 0.2, which is a step 
towards the upcoming Open Automation Framework. We'd like to increase 
the stability and ease of test writing, and make the transition to OAF 
more seamless. Mikeal has written a general doc and a guide to test 
writing. Additionally, the source is well commented. Note that 
QAUITestAppLib has been renamed to ChandlerTestLib. Mikeal gave links to 
the source and the ported tests. Feedback welcome, Dan Steinicke will be 
the point of contact for CATS.

*Checkpoint build*
Dan gave the report for the checkpoint build:

*Alpha3 branch*
We got under the 10 code change bug mark (8) on Thurs, July 6. Heikki 
moved the target milestone to alpha4 for all test related bugs. Next 
Monday's checkpoint build will be on the branch only.

Bear created a branch, the trunk is open for alpha4 work. The alpha3 
branch is restricted -- only commits with bugcouncil approved bugs and 
code review.

*GCJ upgraded on Windows*
Andi upgraded gcj on Windows to fix a bug (6072). "make compilers" is 
required if you are doing full builds on Windows.

Bear noted that the compiler tarball is compressed using bzip2 and that 
GCJ_HOME/GCJ_VER need to be set as a pair (unless you let the makefile 
handle it).

Interns and SoC projects
*Contacts/Address Book*
Ernesto modified his plan based on feedback; conforming to vCard will be 
his first task, then import/export to vCard. Dynamic detail views ala 
OSX's address book will be a bigger challenge than the schema: the 
display/editor for creating an arbitrary number of fields, and the 
display/editor for tagging each field (home, work, etc.). Ernesto asked 
for examples in Chandler. Ernesto explained that he was thinking about a 
"see everything related to this contact popup" to display links. He 
pointed out that contacts already have bidirectional links to other 
items. In response to Ted's question about propagation, Ernesto 
explained that some actions might apply to the group as an item (e.g. 
add group to office hour event), but other actions  apply to each item 
in the group (e.g. sending an email to all members of the group). 
Ernesto explained that ContactPerson and ContactGroup are currently both 
subclasses of an abstract Contact superclass. It might work to make 
groups collections, but raises questions: allow non-contact items to be 
added to the collection? any collection can become a group if it 
contains a contact? Also, adding groups to the sidebar or requiring them 
to live there won't be practical.

Bryan observed that Ernesto might want arbitrary sets of repeating 
blocks (e.g. a value editor and a label editor for each of several email 
addresses.) The detail view currently only supports fixed sets of blocks 
for a particular Kind. Bryan suggests starting with a detail view that 
only displays one; once that is working he can help expand it.

Ernesto asked if there was a table view, and gave a screenshot of a 
possible UI. Grant and Bryan agreed that a table widget would be a way 
around the current detail view limitations. They both pointed out that 
the limitation is the current detail view block architecture, not wx. 
Grant gave pointers to Table.py and code that makes use of it. Grant 
also suggested writing unit tests for vCard import with sample data, he 
offered help in setting that up.

John suggested the architecture could support a variable number of 
fields by changing the method on the detail view's BranchPointBlock that 
returns a tree of blocks. He questioned if this work would be consistent 
with Chandler's design. He also noted that going down this path will 
likely require some working out of snags. Ted responded that Ernesto 
will be working with Mimi on UI review, so the design they work out 
should be consistent with the Chandler design.

Bryan gave more details about a question Ernesto asked in IRC: how to 
display ContactGroup.countMembers() in the detail view. Bryan suggested 
creating a Calculated attribute around the countMembers() method; this 
adds type info that guides the attribute-editor picking mechanism. He 
also gave details on how to hook up to StaticStringAttributeEditor. He 
noted that it might not do the right thing for numeric attributes, so a 
tweak or a different attribute editor might be needed.

*Chandler IMAP server parcel*
Travis sent out his IMAP server parcel. IMAP mail clients should be able 
to "see" Chandler, and enable the user to drag email into Chandler. The 
README.txt has instructions on how to set this up in Mail.app and 
Thunderbird -- the parcel has been tested on these clients. Testing on 
Outlook welcome. Travis asked for a review on his use of the repository 
APIs -- he marked specific questions in the code with #XXX. He'll have a 
subversion sandbox setup soon.

Excited about the IMAP parcel working, Mimi asked questions about 
additional features to flush out the workflow. How smart is Chandler 
when an email is dragged into its repository? Can Chandler: (1) identify 
that an email was sent from Chandler and reconstruct the (stamped) item 
from the email? (2) Identify an email was sent from Chandler and that 
the email is really the same item as an item already in the repository? 
(3) Identify an email was sent from Chandler and is really an update to 
an item you already have in your repository?

Andi reviewed Travis' parcel:

Dev projects
*Reminders when Chandler GUI is not visible*
Grant started a discussion about how to implement the feature of giving 
the user reminders even when the Chandler UI is not up and running (Bug 
5407). He noted platform specific differences, and asked for input on 
non-mac OS-specific services. How do we get a background process running 
whenever the user is logged in? On the mac, you can add a background app 
to the user's list of login items; launchd may be an option in Tiger. Is 
the Windows Service facility the right approach? Linux? Grant described 
4 options from there: (1) Two separate processes, app and service, both 
accessing the repository. (2) Two processes, but the background daemon 
doesn't talk to the repository -- use named pipes or a file or some 
other variant. (3) Have two processes, but do a handshake at launch/quit 
-- only one is responsible for displaying reminders at any given time. 
(4) Have one process, but add ability to switch between full UI and 
background mode.

PJE suggested using the OS's scheduling facilities to run things when 
they are actually scheduled. The program wouldn't need to run all the 
time. Alternatively, run something like a sleep command followed by a 
notifier for low resource usage. Windows also has a notion of "startup 
entries" -- not sure if services launch at login. For option #2, PJE 
suggested XML-RPC. Alternatively, dump reminder files in a directory. 
You have to get some details right wrt naming files, deleting files and 
processing changes -- think of the directory as a message queue, not a 
database. The approach is robust -- no locking issues, nothing 
corrupted, no platform differences.

Bear also discussed the flat file idea, any low impact program could sit 
in the task tray/status bar, run through its paces and then go to sleep. 
The notification process could be OS specific: Growl for OSX, Popup 
dialog for Windows, etc. The program could detect Chandler and 
communicate with it for other value added services. Bear noted that each 
OS provides an area for programs that get started when the user logs 
into the system.

Andi explained that (1) would work. Andi explained that repository files 
must be stored on a file system that supports proper locks. Berkeley DB 
supports multiple processes accessing the repository as well as multiple 
threads. Andi suggested that multiple processes, one for each task, 
seems cleaner.

*Repository documentation*
Ted asked Andi if his EuroPython slides would be a good starting point, 
if they included some of the content Heikki asked for. Andi sent a link 
to the slides. As a starting point he will add some posts to the 
chandlerdb blog answering specific questions from Markku, starting with 
code structure and organization.

*Sharing, information model, dump/reload*
PJE brought a conversation with Morgen about the sharing format to the 
list. Morgen asked about using Google's Data API for sharing (an 
extension of Atom), offering an interop advantage. PJE pointed out that 
it doesn't really have a uniform, elementary information model. He gave 
gd:recurrence as an example, which embeds vobject in the XML model. PJE 
explained that the Chandler information model can be described as a 
meta-schema defining what schema we can express in Chandler. Elaborating 
on "elementary information model", PJE argued that its useful to have a 
simpler model that can express the same ideas for an exchange format, 
for dump/reload, etc. A simpler model can be more robust in the face of 
upgradeability and data interchange. The information model is 
representation-independent, and can be expressed in XML, Python pickles, 

Morgen gave RDF as an example of an information model (a graph data 
model that can be expressed in RDF-XML or N3). Phillip explained that 
having an explicitly specified information model allows systems 
supporting that model to guarantee what is supported storing, querying, 
and retrieving, separate from the representation format. The stack: (1) 
Application/domain model, (2) information model, (3) representation 
format. Parcel developers will have to define a mapping from the domain 
model to the information model. The information model must remain stable 
(only added to). Multiple representation formats are possible, and the 
domain model can evolve over time. The mapping between 1 and 2 could be 
considered a layer in and of itself. PJE noted that defining the API 
around the information model is an interesting problem. He's been 
thinking about dump and reload -- the sharing use cases have different 
demands. Sharing involves incremental modifications to items, and 
dump/reload only cares about changes to the information model, where 
sharing cares about domain model changes.

Morgen summarized where we're at wrt the sharing format on a wiki page, 
which lists requirements and outlines the proposals that have been made 
so far. The discussion will continue on the cosmo-dev mailing list.

Brian K sent out demo code with 3 egg projects: python code + 
localizations, only localizations, localization files for a project in 
another egg. The external API might change but the examples give a good 
idea of how things will work.

Self assigned projects
Heikki released M2Crypto 0.16 on Wednesday, July 5. This was a 
significant release: it fixed all known regressions and memory leaks, 
and integrated new features from other developers. He also added i18n 
support, which we'll be needing in Chandler. 0.16 has already been added 
to the Fedora Core package system. Heikki also included some comments 
from happy users.

Meetings and announcements
*Wiki spam changes*
IT installed a plugin to combat the increase in wiki spam (a source of 
wiki slowness). Let Bear know if you have problems adding or editing 

More information about the chandler-dev mailing list