[Dev] Weekly Status Report 10 October 2003
John Anderson
john at osafoundation.org
Sun Oct 12 09:56:51 PDT 2003
*Last Week:*
* Plan: Finish removing ZODB from Chandler, except where features of
the repository makes it impractical.
* Actual: Done. See detailed repository discussion below
* Plan: Follow-up with Andi to resolve remaining repository problems.
* Actual: Done. Andi, Brian, Michael, Katie, Stuart and I all met
for a very productive meeting in which we came up with good
solutions for all the technical problems.
* Plan: Follow-up with Katie on the design for parcel loading.
* Actual: Done
* Plan: Follow-up with Jed on his progress with document editing.
* Actual: Done
* Plan: Attend another data meeting.
* Actual: Done
* Plan: Work on the design for programming CPIA blocks.
* Actual: Made a small amount of progress thinking through a design
proposal.
* Also: Met briefly with Ducky to discuss documentation for the
repository.
* Repository Discussion: I'm now able to run Chandler and see the
MrMenus viewer parcel build completely on top of our repository.
I've also converted the calendar viewer parcel (however it's not
fully debugged), but none of the other viewer parcels. In the
process of using our new repository I ran into the following snags:
* I spent a few days tracking down a particularly thorny repository
bug. The symptom was that occasional random items were not being
persisted, but it wasn't always reproducible. It turned out to be
caused by ZaoBao using the repository in a different thread. The
repository turned out not to be thread safe. I suspect similar
bugs to occur with other parts of the code that use threads, e.g.
Notifications. Until the repository can be used from multiple
threads, we proposed throwing an exception when use occurs from
different threads.
* When using Items without pre-existing schema, it isn't possible to
add an item reference to a list. Doing so causes the item
reference not to be persisted. The situation comes up in numerous
places in Chandler. Currently it has the consequence that running
Chandler without an empty repository fails. We have a proposed
solution which built on ideas that came up in last week's
repository meeting.
* Lists in our repository are currently implemented as bidirectional
linked lists. One consequence of this design is that large lists
can be sparsely loaded. Another consequence is that lists cannot
be randomly accessed by indexing as in Python lists or arrays in
other languages, e.g. to get to the n'th item you must follow n
references. This design precludes efficient use of some common
algorithms that depend upon indexing, for example binary search
and quick sort (e.g. the Python list sort function). Because
binary search comes up so often in sorted collections, I believe
we will end up needing to implement a list that can be indexed
quickly. There are no plans to implement this kind of list.
* One of the advantages of Python, and other interpreted languages,
is the ability to store references in collections and lists -- in
fact there are no restrictions on where you can store different
types of data. Our repository design differs from Python, in that
it only allows for references to be stored in special reference
collections. Eventually I think this will end up being too
restrictive.
* I implemented a simple solution to the schema evolution problem
for Viewer's model data using ZODB's __setstate__ function. This
solution depended upon the ability to migrate the data to a new
schema from within __setstate__. Our new repository doesn't allow
this, so I need to come up with a different solution.
*Next Week:*
* Plan: Incorporate changes to the repository that allow Chandler to
run on the new repository with MrMenus and Calendar. I don't plan
to convert the remaining Viewer Parcels to the new repository
because Viewer Parcels are going to be superseded by CPIA
documents. However, I will send out instructions in e-mail on how
to do the conversion for anyone who is interested in converting
their Viewer Parcels.
* Plan: Check-in my changes to Chandler to use the new repository.
* Plan: Solve the schema evolution problem as well as it was solved
using ZODB in the previous design.
* Plan: Remove the mountains of old repository code in CVS.
* Plan: Attend another data meeting and discuss the repository
issues described above.
* Plan: Work on the design for programming CPIA blocks.
* Plan: Follow-up with Katie on the design for parcel loading.
* Plan: Follow-up with Jed on his progress with document editing.
More information about the Dev
mailing list