Platform team meeting 20 March 2007

Agenda

• QotF: How should we structure/coordinate work during the 3 week period that we're focusing on performance?
• Q2: Any code reviews we should schedule, now that we are nearing feature freeze?
• α5
  • EIM/sharing
  • Dump/reload
• Demos this week? (Reid will be doing conflict management UI)

Notes

• Q:
  • Heikki: posting to dev -- share tips and tricks, findings on mailing list
  • Morgen: helpful to have explicit list of goals and scenarios that we are trying to optimize. Central place where we could go to say, "I'm working on this particular perf program". Special query or bugzilla table? Heikki: you can query
  • Grant: recurrence
  • PJE: design review will pull Morgen in after meeting
  • Bear: a lot of APIs put in for internal people, might be a good time for people to send info to mailing list (wiki pages, examples, doctests)
  • Andi: code reviews more interesting if looking for something specific

• Recurrence review: Jeffrey, Grant and other apps people
• EIM:
  • still waiting on Cosmo (getting tickets back when publishing via morse code) -- that will make a better demo
  • waiting on event modification from Jeffrey (probably end of this week), mail from bkirsch
  • next: CalDAV on top of EIM, then we can get rid of dual fork (waiting on Jeffrey for that)
  • UI tweaks for Mimi for publish dialog
  • Subscribe dialog: never had checkboxes for sharing optional pieces -- the publisher was in charge of chosing what gets filtered. We might need to add those checkboxes to subscribe. Any subscriber controls whether.
  • Can start doing end to end testing once the translators land.
  • Morgen -- automated chandler -> cosmo -> chandler, but don't know how to test chandler -> cosmo -> cosmoui
• Dump/reload
  • Sharing related stuff done, couple days more work
  • Started collection translator, need that, checked in a couple really basic record types, John is working on those now
  • Modified dump/reload code to identify schema items not just content items, FYI
• Risk factors or worries:
  • Two issues outstanding having to do with inheritance. If you create multiple record types for multiple inheritance situation, recreate the item you can get yourself wedged. Make one item a base class w/out seeing record for combination of base classes -- no way to reconcile those two classes. PJE and Morgen worked out a solution. New twist -- similar ordering issue in single inheritance case. Only runs init of type you create -- item level init but not collection level init. Both sorta the same problem -- before receiving entire item, need to know what the type of item will be. Could add type to base record. Morgen had suggested that at some point. Can work around without having type in base item -- but will use more memory for dump and reload, have to wait until we've seen all records for something. Need to load everything into memory and do everything in right order. Needs to be resolved one way or another. May be able to figure out proper order and be able to tell if we've seen all records for entire item -- more complex solution. May be other risks with that solution. How to identify the type in a way that works? Don't have consistent UUIDs for the type -- need a way to identify the type. May have to change base schema thing again & come up with type identification.
    • Bear: Only needed for dump and reload? PJE: So far -- we haven't encountered the situation -- accident of types used in sharing not dump/reload. Bear: can we only write out type info for dump/reload? PJE: that is possible. For the moment, we are guaranteeing order is same read-in as write-out.
    • Grant: in old sharing world, couldn't rely on init being called. Morgen: you could rely on init not being called.
    • PJE: what if you change the type and you share it. Better to fail fast? Or take care of the annoying case, and have the update case bite them later?
    • PJE: how to identify the types? Can't use a class name, that class name might not mean anything. Practicality of having type information at all might not mean anything.
    • PJE: There is a solution (if not too much disorder to the items/pathological) for handling that can be done with all data we have. How large an effort is it to write the code that would do that?
    • Solving the John problem is easy if we are willing to expend memory. To do without memory is more complex. Bear: running out of memory in dump/reload case would be pretty catastrophic for the user. PJE: no way to conclusively prove that you've seen all data types. No point in the fancy algorithm.
  • PJE will think this through. Decision pending. Least wriggly can of worms sounds like the type information, if only for dump/reload. We can refer directly to record types in the data stream. What if: record type is sole intention, you have now received all of the data for this item -- end of type stream marker of sorts. Translator's import would pull all the type information it has been assembling for that item and apply it. Correct init would get called on the item -- fixing multiple inheritance and lack of init problem. If we have a way to guarantee ordering, this works. Need to look at how order is determined. Translators have an export item method, yields methods. Dump and reload translator could yield an end-of-item record at the end of that process.
• Heikki: been working on password branch -- getting close to land. Would be nice to get cycles from Morgen, bkirsch, Grant to find any places that Heikki might have missed. One more issues that Heikki needs to get fixed. Ring a bell? Current branch has a problem where default accounts seem to share a password. Grant: Using default value? Heikki: No. Heikki: not planning on changing any plugins to use the encrypted password. Ok. Morgen: Does encrypted password code work transparently? Heikki: should work transparently. Password is no longer a unicode stream -- it is an object and you need to call encrypt/decrypt. Heikki has changed all code that he has noticed. Should be pretty obvious when things break. Grant: you could run headless, and do a query for password kinds, and see what you get. Pop up a dialog and ask for the master password. Default master password is empty. Like firefox? Probably.
• Demos?
  • Heikki: password if he gets past this problem
  • Plugin? Andi: No, waiting until a few more problems are solved.

Status

Andi

• http://kumu.osafoundation.org/~vajda/logs.cgi

Katie

• Progress
  • draft position statement
  • eng wiki section
  • QA sessions
  • item-in-multiple collections security issue (managed to trigger this)
• Plan
  • realistic data sets for perf testing
  • tenets for .1 release after Preview
  • menu fixes
  • list summaries

Morgen

• Progress
  • Added "Needs reply status" to publish/manage dialog (only works for morsecode)
  • Worked on sharing-related dump/reload, plus collections
  • Added hasBeenSent and needsReply EIM fields
  • Tweaked the API for seeing if there are conflicts
  • Added EIM support for lastModification
  • Fixed an issue with edit/update inbound( ) where the previous agreed upon state was discarded incorrectly the first time we get a reply
• Plan
  • Finish sharing-related dump/reload translator
  • Continue Chandler/Cosmo interop work

Grant

• Progress
• 6880: Enable "All" button in the dialog when making edits to an instance of a recurring event
• 8127: Do triage-status reminders need to be items?
• 8222: Apply all recurrence change to the selected occurrence
• Cleaned up an issue where VTODOs roundtripped into VEVENTS in Chandler.
• Wrote up VTODO notes for design@ list.
• Fixed a couple of unit test failures in the triage_recurrence branch.
• With AndiVajda's help, made some further progress on correctly propagating notifications for recurring events.
• Experimented with a performance change: making EventStamp.effectiveStartTime be an actual attribute, not a Calculated. Seems to improve calendar import; some further investigation is required.
• Some work on Bug 7446 (a refactoring of application.dialogs.RecurrenceDialog to work better with stamps).
• In my clone, fixed Bug 8316 (the part where we refresh the minicalendar incorrectly for recurring events).
• Sent review of domain model schema that is currently unsupported by EIM translators.
• Trying to reproduce (or have Aparna reproduce) some issues with sharing/recurrence in trunk (8292, 8243).

• Plan
  • Some EIM translator work.
  • Remaining α5 features (Edit/Update: 8405(changes to send behaviour), 2062 (domain model support for lastModifiedBy).

PJE

• Progress
  • Misc. ongoing assistance & support w/Chandler APIs, Python libraries, etc.
  • Refactored dump/reload pickling code to support movable record types and to use a faster pickling protocol with better memoization (i.e. a more compact format)
  • Assist w/8328, close 8368
  • Design and implement prototype inter-thread communication decorators and utilities for use by Heikki's "master password" system to fix race conditions and thread shutdown problems
  • Design EIM translator modification to deal with multiple-inheritance problems during dump/reload of sharing-specific classes
• Plan
  • Implement the multiple-inheritance fix
  • Add localization of field titles for conflict resolution UI
  • Release setuptools 0.6c6