This page is for lessons learned / feedaback on the Sprint

Day 1

• We need documentation of all the available repository types that can be used in Schema
• We need documentation of the various block types, and what they are capable of doing.
• In order to faciltate debugging of parcel loading, it would be good to be able to print parcels as they load, or otherwise display the loaded parcels
  • I thought MorgenSagen had implemented this, should work in debug mode. -- HeikkiToivonen - 04 Apr 2005
• When a parcel loading error occurs, the error message should display the path to the parcel.xml that Chandler was trying to load
  • I thought MorgenSagen had implemented this, should work in debug mode. -- HeikkiToivonen - 04 Apr 2005
• tutorial makes too many references to osaf.examples.... probably want to just move zaobao or a similar example out to a new sample? Confusing to know what is part of "osaf"/chandler and what is part of the example
• when PARCELPATH fails to find anything, it is silent - should complain
• "Reason not recorded" parcel.xml error: what was going on? Error with 'NoneType' does not have attribute getItemChild (???)
• If a cloud has no endpoint, the repository viewer blows up
• In repository viewer, Kind definition should show actual Kind path so that its easy to write myKindPath
• Is myKindID really necessary?
• Still need to rationalize CPIA view vs. Repository view... and can we eliminate Globals.views[0] and instead get the CPIA view from the event in the controller?

Followup discussion:

• Getting rid of parcel paths: developers shouldn't have to deal with paths - everything should be, by default, relative to the user's current parcel
  • one suggestion: unify "itsName" and so forth, so that if you have <Kind itsName="foo"&gt, then it automatically tries to get the implementation from parcel.py, class foo, in the current parcel's directory. (or in foo.py, as class foo) - this as a default to the attribute

Day 2:

• "DetailTrunkSubtree" is kind of obtuse - maybe something simpler like DetailBlocks^? or something? (and technically its not a subtree, since the tree isn't swapped in directly as a tree of blocks, but rather aggregated with other DetailTrunkSubtree^?)
• Missing zbSchema declaration in tutorial - probably should just be "zaobao" so that kind references are obvious
• Need an easy way in the tutorial to distinguish between what the user needs to change (i.e. is zaobao-specific) and what should stay the same... user tried to change a namespace from osaf/framework/blocks to samples/flickr/blocks - oops!
• We'll need some more support for parcels to do preference panels. An example would be username password type stuff. Since all our dialogs work on Items, we probably ought to have a Chandler defined kind for username/password, so that 3rd parties aren't constantly defining it.
• in HTMLDetailArea^? / ZaoBaoItemDetail^?, why do we have to do the itsView check at the top?
• when using PARCELPATH, paths on PARCELPATH should not be inside the Chandler application (on Windows)
• Stamping issue: We forgot to declare for a Kind (even though we had declared myKindPath in the python) - another case where automatic Kind/class mapping would be great.
• calendar is blowing up when a stamped item doesn't have a displayName attribute!
• parcel loading shouldn't completely break if a class can't be loaded (should only warn)
• "Class" type should deal better with whitespace/control characters - we had a <wakeupCallClass> that had the class name on a separate line, which was giving some really wierd parcel loading errors
• Lightbulb goes off over Alec's head when Katie and Ted are explaining global attributes (and the smart-bidirectionality) to Jeffrey. "This is huge!" he exclaims. Everyone feels bad that Alec didn't understand this all before.
• We need some smart validation to make sure the Kind/class hierarchy matches...

Other stuff

• We directed people to the repository viewer (web server) but it isn't mentioned in the tutorial...

Notes from the IRC session 4/6/2005

Stuff to fix

• "fix logging" - apparently a URL from hazmat
• look in chandler.log - add that to the tutorial
• Logging should be accessible from the UI - maybe a menu that brings up the log in a window

Questions from developers

• How much typing did the developers do?
• Yay for tinderbox, but how test-driven are we? Lots of discussion about integrated vs. external tests
• lots of discussion on parcel.xml, and where we want to go from there - ended up mostly being chandler developers