[Chandler-dev] [Sum] May 8 - 14

[Katie Capps Parlante]

Morgen asked for help testing the branch created for background sync. He 
has a wiki page tracking what is working and what is not working. After 
we've shaken out a few more bugs, Morgen expects to land the changes at 
the beginning of alpha3.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005887.html

Alec added a method to UITestView, Check_Equality(). This method 
compares two values and handles generating the ReportPass/Failure calls.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005889.html

Andi noted that most functional tests eat exceptions. Andi added a 
method to QALogger, ReportException(). This method appends a traceback 
to the log before calling ReportFailure(). The patch is waiting on 
alpha2 approval.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005890.html

Mikeal noted that Chandler not running on intel mac is increasingly 
becoming a problem as new people get new intel mac machines. Mikeal 
filed a bug to track the known problems.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005891.html

Philippe forwarded a note to the list from Xun Luo, who built chandler 
0.7 alpha on Ubuntu 5.10. Xun noted that libstdc++.so.6 in debug/lib was 
outdated (and caused a runtime error once chandler was built). He got 
the build to work by linking to libstdc++.so.6.0.5.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005892.html

Phillip Eby posted an overview of his thinking about "dump and reload", 
designed to deal with data migration between releases. The plan was to 
have a stable external format in which to dump data, then be able to 
reload it into the same or newer versions of Chandler. Phillip noted 
competing forces: (1) ability to perform upgrades flexibly (2) 
implementation complexity (3) API complexity for parcel writers (3) 
effective support for parcel modularity (4) performance. He also listed 
  preliminary design implications (1) simple data structures (2) 
shouldn't use nesting structures to store large sequences (3) 
notifications disabled during load (4) parcels allowed access to stream 
of records loaded (5) parcels should be given before and after hooks. 
Phillip brings up other open issues. How do we give a clean per-parcel 
API for parcel developers while being efficient, i.e. only walking the 
repository once while dumping? He described a solution using iterators, 
so that at reload time the records could be read "interleaved" or parcel 
by parcel, even as they were written by walking the repository. The next 
issue was how to model many to many and ordered relationships. Many to 
many relationships require extra records to record the relationship. 
Phillip introduced a new descriptor, "Sequence", to describe ordered 
sequences. In "One - Sequence" relationships or "Many - Sequence" 
relationships, the order of the records can preserve the sequence. 
Sequence - Sequence relationships pose a problem, and Phillip suggested 
we not support these types of relationships, pointing out that they are 
possibly not stable or meaningful anyway. Phillip asked for feedback on 
his thoughts before writing a more concrete proposal.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005895.html

Morgen brought up the discussions about the new "sharing format", noting 
that it has some of the same requirements: (1) stable format, (2) 
maintain ref-collection order, (3) avoiding problems with onValueChanged 
calls during sync, etc. Is there an opportunity for reuse? The sharing 
format may be something as simple as RDF triples.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005897.html

Phillip responded that both systems would benefit from getting rid of 
sequence to sequence birefs. He noted that from the point of view of the 
API and framework, the data will essentially be tuples of elementary 
types (not unlike relational database tables). The main difference from 
a relational database is that processing will occur on a stream of 
records, which may at certain points be interleaved. Phillip expressed 
concern about the overlap of sharing and dump/reload, noting that parcel 
writers would have to write two sets of similar code to do schema upgrades.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005898.html